Java进阶必备：优雅的告诉面试官消息中间件该如何实现高可用架构？【石杉的架构笔记】

时间 2019-11-07

标签 java 进阶必备优雅告诉面试消息中间件如何实现可用架构石杉的架构笔记栏目 Java 繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）程序员

周一至周五早8点半！精品技术文章准时送上！面试

（1）背景引入

这篇文章，咱们来聊一下消息中间件高可用架构的一些原理。微服务

对于一个合格的高级Java工程师而言，你确定会碰到在系统里用到MQ的场景，那么这个时候你须要基于你的业务场景和需求，考虑在使用MQ的时候可能遇到的一些技术问题。高并发

接着，你必须得针对这些技术问题设计一套完整的技术方案。

你须要从消息的订阅模式、消息的生产到消费全链路不丢数据、消息中间件自己如何保证高可用，等各个角度切入，来考虑好你的系统和MQ对接以后的完整技术方案。

因此，本文就来聊聊消息中间件高可用的架构原理。

（2）先来思考一下消息中间件的可用性问题

我们先抛开各类具体的技术，就来思考一下，啥是MQ的可用性问题？

你们看看下面的图，其实道理很简单，假如你的MQ就部署在一台机器上，那么正常状况下，生产者都会发送消息到MQ去，而后让消费者获取到。

可是万一天有不测风云，MQ部署的那台机器，由于一些莫名的缘由，MQ本身自己的进程挂掉了，或者是那台机器直接就宕机了，那么此时怎么办呢？

很尴尬，是否是，结果是很明显的，生产者无法发送数据出去，而后消费者也无法获取到数据了。

而后整个系统不就完蛋了？由于系统的核心流程根本没法跑通了，对不对？

MQ宕机就直接致使你的系统自己也故障了，而后可能会致使你的公司对外的APP、网站等产品就没法运做了，用户没法使用大家公司的服务了。

若是大家公司是电商平台、外卖平台、社交平台。那么来这么一出，不是会致使公司损失惨重？

若是你的系统持续几个小时没法被人使用，原本你公司电商平台一天营收能够达到1亿，结果如今致使几个小时内没法下单购买商品，最后当天营收就5000万，那么你的公司是否是直接活生生损失了5000万？

这个真的不是开玩笑的，若是你们留意互联网行业的新闻的话和小道消息的话，就应该知道近几年一些大型互联网公司都出现过相似的状况，损失惨重，我们作码农的就得被祭天了是否是？

（3）集群化部署 + 数据多副本冗余

好，问题来了！如今你感受一个MQ中间件应该如何实现高可用呢？

这里的方式有不少种，好比说数据多副本冗余，集群镜像同步机制，咱们就抛开具体的技术来从本质层面思考一下MQ集群实现高可用的几种方式。

先来看下面的一张图，假设咱们写到MQ的数据都被多副本冗余了，也就是你写的每一条消息都被复制到了其余的机器上去了。

那么此时任何一台机器宕机，彷佛都不会影响咱们跟MQ继续通讯，并且写出去的数据彷佛也都还在。

上面的图里，MQ采用集群模式部署到了2台机器上去，而后生产者给其中一台机器写入一条消息，该机器自动同步复制给另一台机器。

此时数据在2台机器上，就有2个副本了，那么若是第一台机器宕机了，会影响咱们吗？

答案是：不会。

由于数据自己是多副本冗余的，此时消费者彻底能够从第二台机器消费到这条消息，而且生产者还能够继续给第二台机器写入消息，数据没丢失。

并且，系统根本不用中断流程，还能够继续运行，咱们看下面的图。

这种感受是否是很棒？实际上这种MQ集群化部署架构以及数据多副本冗余机制，是很是常见的一种高可用架构。

Kafka这个极为优秀的消息中间件，就是采用的这种架构保证高可用、数据容错性。

（4）多副本同步复制强制要求

可是这里你要思考另外几个问题，第一个就是：你在写数据到其中一台机器的时候，是否是得要求，必须得让那台机器复制数据到另一台机器了，保证集群里必定有这条数据双副本了，才能够认为本次写成功了？

没错，假如你要是不能保证这一点，好比你就写数据给了其中一台机器，而后他还没来得及复制给另一台机器呢，直接第一台机器就宕机了。

此时虽然你能够继续基于第二台机器发送消息和消费消息，可是你刚才发送的一条消息就丢失了。

你们看下面的图来理解一下这个场景。

因此对于采用这种机制的时候，你必须得让生产者经过一些参数的设置，保证说写一条消息到某台机器，他必须同步这条消息到另一台机器成功，集群里有双副本了，而后此时才能够认为这条消息写成功了。

但凡刚写一台机器他就宕机，还没来得及复制到另一台机器的话，本次写应该报错失败，而后你应该重试再次写入数据到MQ集群里去。

你们看看下面的图。只要你一次写成功了，他就保证确定已经同步数据为双副本了，此时哪怕一台机器宕机，数据不会丢失，生产和消费均可以有条不紊的继续进行。

（5）多机器承载多副本强制要求

第二个问题，假如说如今你的集群中原本有两台机器，如今宕机了其中的一台，只有一台机器了，你还能容许你的生产者对惟一的一台机器继续写入数据吗？

答案是：否。

由于若是集群里只有一台机器能够承载写入，那么万一剩余的一台机器又宕机了呢？是否是仍是会致使数据丢失，集群完蛋？

因此说，你的生产者同理应该基于参数设置一下，集群里必须有超过2台机器能够接收你的数据副本复制。

不然若是只有1台机器能够接受你的数据副本复制的话，那么仍是算了。

你们看看下面的图，感觉一下那个场景。

假设集群里有3台机器，那么其中一台宕机了，你后续再写入另一台的时候，判断一下集群里还有剩余两台机器，足以保证数据双副本的高可用性和容错性，因此能够继续正常的写入数据到MQ集群里去。

实际上，上面说的那一整套的机制，在Kafka里均可以采用，他有对应的一些参数能够配置数据有几个副本，包括你每次写入必须复制到几台机器才能够算成功，不然就要从新发送，以及你的集群剩余机器必须能够承载几个副本才能继续写入数据。

经过这一整套方案的设计和基于具体技术的落地，才能够保证在集群化部署的状况下，集群必须有几台机器承载多副本，同时数据写入以后必须是保证多副本冗余的。

此时，任何机器宕机，数据都不会丢失，还能够正常让系统继续运行。

（6）架构原理与技术无关性

其实本文对消息中间件的集群高可用架构的探讨，是彻底脱离于某个具体技术的，很是朴素的从本质的原理层面来讨论这个话题。

具体的RabbitMQ、Kafka、RocketMQ等各类不一样的消息中间件，对这种高可用架构的实现，都有必定的类似想通性，可是也都有各自不一样的技术实现，以及相对应的区别。

后面咱们再经过不一样的文章，以各类MQ中间件的具体技术实现举例来讨论一下相关的架构是如何落地的。

END

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授