欢迎来到头条号：石杉的结构笔记
星期一到星期五早上8点半！ 精品的技术文章会按时发送！
目录
(1)背景导入(2)首先考虑消息中间件的可用性
(3)集群化导入数据的多个复制冗余化
(4)多拷贝同步拷贝强制要求
)5)多机装载多拷贝强制要求
(6)体系结构原理与技术无关
（1）背景引入
本文介绍了消息中间件高可用性体系结构的一些原理
对于合格的高级Java工程师来说，一定会遇到在系统中使用MQ的场面。 那么，这个时候，就需要根据你的业务场景和需求，考虑使用MQ时可能遇到的技术问题。
其次，必须针对这些技术问题设计完整的技术方案。
需要从消息订阅模型、从消息生产中消耗全部链接不丢失数据、消息中间件自身如何保证高可用性等多个角度进行切入，考虑系统与MQ对接后的完整技术方案
因此，本文介绍了消息中间件高可用性体系结构的原理。
（2）先来思考一下消息中间件的可用性问题
首先，我们无视各种具体技术，来考虑一下MQ的可用性问题是什么。
请看下图。 其实道理很简单。 如果你的MQ配备在一台机器上，通常生产者会向MQ发送消息，让消费者得到。
图不清楚，请转到同名的公众号看看
但是，万一zxdxt、MQ导入的机器，由于某种原因，MQ自身的进程死机了，或者该机器就这样瘫痪了，该怎么办呢？
真尴尬啊。 结果很明显。 生产者不能发送数据。 而且，消费者也无法获取数据。
然后整个系统不是结束了吗？ 因为系统的中心过程不好用了，对吧？
MQ停机的话，你的系统本身也会发生故障。 而且，你公司的对外APP和网站等产品可能会失灵，用户无法使用你公司的服务。
如果你的公司是EC平台、外卖平台、社交平台的话。 那么，这样出去的话，公司的损失会很大吧？
如果你的系统几个小时不使用，本来你公司的EC平台一天的收入可以达到1亿，结果现在几个小时内不能订购和购买商品，最后当天的收入变成了5000万，你的公司直接损失了5000万
这真的不是开玩笑。 如果大家注意互联网行业的新闻和小道消息，应该知道这几年几大互联网公司出现了类似的情况，蒙受了巨大的损失。 我们务农的人必须祭天，不是吗？
（3）集群化部署 + 数据多副本冗余
是的，发生了问题！ 你认为现在MQ中间件应该如何实现高可用性？
这里的方式有很多种。 例如，数据的多拷贝冗余化、集群的镜像同步机制等。 我们抛开具体技术，从本质层面来考虑MQ集群实现高可用性的几种方式。
让我们先看看下图。 我们写在MQ上的数据都是多份拷贝冗余的。 也就是说，你写的所有消息都被复制到了其他机器上。
此时，任何机器出现故障似乎都不会影响与MQ继续通信。 另外，写入的数据似乎也还在。
图不清楚，请转到同名的公众号看看
="ql-align-justify">上面的图里，MQ采用集群模式部署到了2台机器上去，然后生产者给其中一台机器写入一条消息，该机器自动同步复制给另外一台机器。
此时数据在2台机器上，就有2个副本了，那么如果第一台机器宕机了，会影响我们吗？
答案是：不会。
因为数据本身是多副本冗余的，此时消费者完全可以从第二台机器消费到这条消息，并且生产者还可以继续给第二台机器写入消息，数据没丢失。
而且，系统根本不用中断流程，还可以继续运行，我们看下面的图。
如图不清晰，请移步同名公众号查看
这种感觉是不是很棒？实际上这种MQ集群化部署架构以及数据多副本冗余机制，是非常常见的一种高可用架构。
Kafka这个极为优秀的消息中间件，就是采用的这种架构保证高可用、数据容错性。
（4）多副本同步复制强制要求
但是这里你要思考另外几个问题，第一个就是：你在写数据到其中一台机器的时候，是不是得要求，必须得让那台机器复制数据到另外一台机器了，保证集群里一定有这条数据双副本了，才可以认为本次写成功了？
没错，假如你要是不能保证这一点，比如你就写数据给了其中一台机器，然后他还没来得及复制给另外一台机器呢，直接第一台机器就宕机了。
此时虽然你可以继续基于第二台机器发送消息和消费消息，但是你刚才发送的一条消息就丢失了。
大家看下面的图来理解一下这个场景。
如图不清晰，请移步同名公众号查看
所以对于采用这种机制的时候，你必须得让生产者通过一些参数的设置，保证说写一条消息到某台机器，他必须同步这条消息到另外一台机器成功，集群里有双副本了，然后此时才可以认为这条消息写成功了。
但凡刚写一台机器他就宕机，还没来得及复制到另外一台机器的话，本次写应该报错失败，然后你应该重试再次写入数据到MQ集群里去。
大家看看下面的图。只要你一次写成功了，他就保证肯定已经同步数据为双副本了，此时哪怕一台机器宕机，数据不会丢失，生产和消费都可以有条不紊的继续进行。
如图不清晰，请移步同名公众号查看
（5）多机器承载多副本强制要求
第二个问题，假如说现在你的集群中本来有两台机器，现在宕机了其中的一台，只有一台机器了，你还能允许你的生产者对唯一的一台机器继续写入数据吗？
答案是：否。
因为如果集群里只有一台机器可以承载写入，那么万一剩余的一台机器又宕机了呢？是不是还是会导致数据丢失，集群完蛋？
所以说，你的生产者同理应该基于参数设置一下，集群里必须有超过2台机器可以接收你的数据副本复制。
否则如果只有1台机器可以接受你的数据副本复制的话，那么还是算了。
大家看看下面的图，感受一下那个场景。
如图不清晰，请移步同名公众号查看
假设集群里有3台机器，那么其中一台宕机了，你后续再写入另外一台的时候，判断一下集群里还有剩余两台机器，足以保证数据双副本的高可用性和容错性，所以可以继续正常的写入数据到MQ集群里去。
实际上，上面说的那一整套的机制，在Kafka里都可以采用，他有对应的一些参数可以配置数据有几个副本，包括你每次写入必须复制到几台机器才可以算成功，否则就要重新发送，以及你的集群剩余机器必须可以承载几个副本才能继续写入数据。
通过这一整套方案的设计和基于具体技术的落地，才可以保证在集群化部署的情况下，集群必须有几台机器承载多副本，同时数据写入之后必须是保证多副本冗余的。
此时，任何机器宕机，数据都不会丢失，还可以正常让系统继续运行。
（6）架构原理与技术无关性
其实本文对消息中间件的集群高可用架构的探讨，是完全脱离于某个具体技术的，非常朴素的从本质的原理层面来讨论这个话题。
具体的RabbitMQ、Kafka、RocketMQ等各种不同的消息中间件，对这种高可用架构的实现，都有一定的相似想通性，但是也都有各自不同的技术实现，以及相对应的区别。
后面我们再通过不同的文章，以各种MQ中间件的具体技术实现举例来讨论一下相关的架构是如何落地的。
End
如有收获，请帮忙转发，您的鼓励是作者最大的动力，谢谢！
一大波微服务、分布式、高并发、高可用的原创系列文章正在路上,
欢迎关注头条号：石杉的架构笔记
周一至周五早八点半！精品技术文章准时送上！！！
十余年BAT架构经验倾囊相授
推荐阅读
1、拜托！面试请不要再问我Spring Cloud底层原理！
2、微服务注册中心如何承载大型系统的千万级访问？
3、「性能优化之道」每秒上万并发下的Spring Cloud参数优化实战
4、「“剁手党”狂欢的背后」微服务架构如何保障99.99%的高可用？
5、兄弟，用大白话告诉你xwdhl都能看懂的Hadoop架构原理
6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
7、「性能优化的秘密」Hadoop如何将TB级大文件的上传性能优化上百倍
8、拜托，面试请不要再问我TCC分布式事务的实现原理！
9、最终一致性分布式事务如何保障实际生产中99.99%高可用？
10、拜托，面试请不要再问我Redis分布式锁的实现原理
11、Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上？
12、亿级流量系统架构之如何支撑百亿级数据的存储与计算
13、亿级流量系统架构之如何设计高容错分布式计算系统
14、亿级流量系统架构之如何设计承载百亿流量的高性能架构
15、亿级流量系统架构之如何设计每秒十万查询的高并发架构
16、亿级流量系统架构之如何设计全链路99.99%高可用架构
17、七张图彻底讲清楚ZooKeeper分布式锁的实现原理
18、大白话聊聊Java并发面试问题之volatile到底是什么？
19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？
20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？
21、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化
22、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）
23、互联网公司面试官是如何360°无死角考察候选人的？（下篇）
24、「Java进阶面试系列之一」你们系统架构中为何要引入消息中间件？
25、「Java进阶面试系列之二」系统架构引入消息中间件有什么缺点
26、「行走的Offer收割机」一位朋友斩获BAT技术专家Offer的面试经历
27、「Java进阶面试系列之三」消息中间件在你们项目里是如何落地的？
28、扎心！线上服务宕机时，如何保证数据100%不丢失？
29、 一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！
30、「高并发优化实践」10倍请求压力来袭，你的系统会被击垮吗？
31、消息中间件集群崩溃，如何保证百万生产数据不丢失？
32、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？
33、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？
34、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？
35、亿级流量架构第二弹：你的系统真的无懈可击吗？
36、亿级流量系统架构之如何保证百亿流量下的数据一致性（上）
37、亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？
38、亿级流量系统架构之如何保证百亿流量下的数据一致性（下）？
39、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（1）
40、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（2）
41、面试大杀器：消息中间件如何实现消费吞吐量的百倍优化？
42、兄弟，用大白话给你讲xwdhl都能看懂的分布式系统容错架构
43、从团队自研的百万并发中间件系统的内核设计看Java并发性能优化
44、如果20万用户同时访问一个热点缓存，如何优化你的缓存架构？
45、「非广告，纯干货」英语差的程序员如何才能无障碍阅读官方文档？
46、面试最让你手足无措的一个问题：你的系统如何支撑高并发？