Broker的主从架构是怎么实现的？

前言

上一篇文章我们一起聊了聊RocketMQ的NameServer的一些内部工作流程，了解了NameServer的部署和与Broker之间的联系，那么今天我们就来一起聊聊Broker的一些内部原理。

Master Broker与Slave Broker之间的消息同步

看过之前文章的小伙伴们都清楚，Broker是RocketMQ的核心模块，负责接收并存储消息，为了保证整个MQ的高可用，一般情况都会将Broker部署成集群，集群中的每一部分都由Master和Slave组成，那么Master与Slave之间的数据是如何保证同步一致的呢？

是Master主动把数据推送给Slave?还是Slave主动发送请求去Master拉取最新数据？

答案是第二种，RocketMQ的内部原理就是Slave不停的向Master发送请求拉取数据，也就是说这是一种Pull模式拉取消息，而不是Push模式推送消息。

Master Broker与Slave Broker实现读写分离了吗

上边我们了解到，Master Broker主要接收来自系统的请求，之后Slave Broker会向Master Broker发出拉取请求，同步数据。那么，当系统访问Broker获取数据的时候是什么样的过程呢？如果实现了读写分离，是不是Master Broker只负责消息的写入操作，Slave Broker只负责消息的读取呢？

其实不是这样的，当读取数据的时候，是既可能在Master Broker读取数据，也可能在Slave Broker读取数据的。

作为消费者，向MQ获取数据的时候，首先与Master Broker建立连接，并发送请求获取一批消息。

而此时，Master Broker不是直接返回消息给消费者的，而是会根据Master Broker的负载情况以及Slave Broker的同步情况，向消费者建议下次应该从Master Broker获取消息还是应该从Slave Broker获取消息。

具体什么时候会建议去Master Broker获取消息呢？

举个例子，如果在一段时间内Master Broker突然新增了大量的消息，而这时Slave Broker同步这些消息也是需要一定的时间的，所以主从的数据是不一致的，为了保证读取消息的可靠性，就只能从Master Broker获取消息。

那么什么时候会建议去Slave Broker获取消息呢？

再看个例子，如果一段时间内，Master Broker由于业务原因接收了海量的并发请求，导致本身负载很重，这时对于消费者新发来的请求，如果继续从Master Broker获取消息，就会导致性能很慢，而且增加Master Broker服务器的压力，所以这个时候就会建议从Slave Broker获取消息了。

所以我们总结出来，当写入消息的时候，一般是选择Master Broker来写入的，而对于读取消息，从哪里获取数据，要视当时情况而定。所以不能说是完全的读写分离。

如果Slave Broker宕机怎么办

现在我们想想，如果Slave Broker宕机了，对于整体MQ系统来讲，会有多大的影响？

实际上，这种情况是没有太大的影响的，因为我们刚刚已经知道，所有的写请求都会发送给Master Broker，而所有的读请求通过Master Broker也可以进行下去。

所以Slave Broker宕机了，其实不影响整个MQ的运行过程，如果非要说出个影响了，那就是可供读取消息的机器少了一台而已，如果这时候出现海量并发读取消息的情况，性能会变差。

所以，Slave Broker宕机，一般会有监控系统监控的到，维护人员及时手动处理重新启动就可以了。

如果Master Broker宕机怎么办

现在我们假设，Master Broker突然宕机了，对于MQ整体上有什么影响呢.

这种情况对于消息的写入和读取就会产生影响了。但是我们知道，在Slave Broker上是有一份与Master Broker相同的备份数据的，只不过可能存在消息同步的过程中宕机的情况，导致部分数据丢失。

那么RocketMQ可以自动将Slave切换为Master吗？答案是否定的。

在RocketMQ4.5之前，一旦Master发生故障，Slave是没法自动切换成Master提供服务的。

在这种情况下，就需要运维人员手动修改Slave Broker的配置，重启服务将其切换为Master，这样不仅过程麻烦，而且中途还会发生服务不可用的状况，没有真正的实现高可用。

Dledger实现RocketMQ的高可用

在RocketMQ4.5后，针对于上边说到的情况有了新的解决方案，就是Dledger。

小伙伴们一定会问，Dledger是什么呢？

Dledger是一个基于Raft协议实现的机制，暂时知道这里就可以了，至于什么是Raft，Dledger原理这里就先不聊了，那又是一个大的话题，感兴趣的小伙伴可以自行百度了解。

我们主要要聊的是基于Dledger可以实现RocketMQ的高可用主从自动切换效果。

简单的解释一下，就是当Master Broker宕机的时候，就可以在多个Slave Broker中根据Dledger机制进行leader选举，选出一个新的Master对外继续提供服务。整个过程可能在10秒或几十秒的时间，这样的话就实现了主从切换的自动化了。

总结

今天我们主要聊了聊Broker的主从架构，下边的文章我们将继续探索RocketMQ的生产部署架构，欢迎小伙伴们持续关注。

往期文章推荐：

中间件专辑：

什么是消息中间件？主要作用是什么？

常见的消息中间件有哪些？你们是怎么进行技术选型的？

你懂RocketMQ 的架构原理吗？

聊一聊RocketMQ的注册中心NameServer

算法专辑：

和同事谈谈Flood Fill 算法