【RocketMQ】四、Broker的主从架构原理是什么

本文主要介绍RocketMQ消息中间件Broker的主从架构原理

1. Master Broker是如何将消息同步给Slave Broker的

我们都知道，为了保证MQ的数据不丢失而且具备一定的高可用性，一般都是得将Broker部署成Master-Slave模式的，也就是一个Master Broker对应一个Slave Broker。

然后Master需要在接收到消息之后，将数据同步给Slave，这样一旦Master Broker挂了，还有Slave上有一份数据。

那么Master Broker是如何将消息同步给Slave Broker的？是Master Broker主动推送给Slave Broker？还是Slave Broker发送请求到Master Broker去拉取？

答案是第二种，RocketMQ的Master-Slave模式采用的是Slave Broker不停的发送请求到Master Broker去拉取消息。

所以首先要明白这一点，就是RocketMQ自身的Master-Slave模式采取的是Pull模式拉取消息。

2. RocketMQ实现读写分离了吗？

既然Master Broker主要是接收系统的消息写入，然后会同步给Slave Broker，那么其实本质上Slave Broker也应该有一份一样的数据。

那么作为消费者的系统在获取消息的时候，是从Master Broker上获取的，还是从Slave Broker上获取的？答案是有可能从Master Broker获取消息，也有可能从Slave Broker上获取消息。

作为消费者的系统在获取消息的时候会先发送请求到Master Broker上去，请求获取一批消息，此时Master Broker是会返回一批消息给消费者系统的。

然后Master Broker在返回消息给消费者的时候，会根据当时Master Broker的负载情况和Slave Broker的同步情况，向消费者系统建议下一次拉取消息的时候是从Master Broker拉取还是从Slave Broker拉取。

所以在写入消息的时候，通常来说肯定是选择Master Broker去写入的，但是在拉取消息的时候，有可能从Master Broker获取，也可能从Slave Broker去获取，一切都根据当时的情况来定。

3. 如果Slave Broker挂了 有什么影响

如果Slave Broker挂掉了，会对整个系统有影响吗？答案是有一点影响，但是影响不大。

因为消息写入全部是发送到Master Broker的，然后消息获取也可以从Master Broker获取，只不过有一些消息获取可能从Slave Broker去获取。

所以如果Slave Broker挂了，那么此时无论消息写入还是消息拉取，还是可以继续从Master Broker去走，对整体运行不影响，只不过少了Slave Broker，会导致所有读写压力都集中在Master Broker上。

4. 如果Master Broker挂了该怎么办

如果Master Broker突然挂了，会怎样？这个时候就对消息的写入和获取都有一定的影响了，但是其实本质上而言，Slave Broker也是跟Master Broker一样有一份数据在的，只不过Slave Broker上的数据可能有部分没来得及从Master Broker同步，但是此时RocketMQ可以实现直接自动将Slave Broker切换成Master Broker吗？

答案是不能，在RocketMQ 4.5版本之前，都是用Slave Broker同步数据，尽量保证数据不丢失，但是一旦Master故障了，Slave是没办法自动切换成Master的。

所以在这种情况下，如果Master Broker宕机了，这时就得手动做一些运维操作，把Slave Broker重新修改一些配置，重启机器给调整为Master Broker，这时有点麻烦的，会导致中间一段时间不可用。

所以这种Master-Slave模式不是彻底的高可用模式，他没办法自动把Slave切换成Master。

5. 基于Dledger实现RocketMQ高可用自动切换

在RocketMQ 4.5之后，RocketMQ支持了一种新的机制，叫做Dledger，这个东西本身是基于Raft协议实现的一个机制，实现原理和算法有点复杂。

简单来说，把Dledger融入RocketMQ之后，就可以让一个Master Broker对应多个Slave Broker，也就是说一份数据可以有多个副本，比如一个Master Broker对应两个Slave Broker，然后依然会在Master和Slave之间进行数据同步。

此时一旦Master Broker宕机了，就可以在多个副本中通过Dledger技术和Raft协议算法进行leader选举，直接将一个Slave Broker选举为新的Master Broker，然后这个新的Master Broker就可以对外提供服务了。