image.png image.png image.png image.png image.png image.png

Broker 通过主从集群来实现消息高可用。

跟 Kafka 不同的是，RocketMQ 并没有 Master 节点选举功能，而是采用多 Master 多 Slave 的集群架构。

Producer 写入消息时写入 Master 节点，Slave 节点主动从 Master 节点拉取数据来保持跟 Master 节点的数据一致。

Consumer 消费消息时，既可以从 Master 节点拉取数据，也可以从 Slave 节点拉取数据。
到底是从 Master 拉取还是从 Slave 拉取取决于 Master 节点的负载和 Slave 的同步情况 。
如果 Master 负载很高，Master 会通知 Consumer 从 Slave 拉取消息，而如果 Slave 同步消息进度延后，则 Master 会通知 Consumer 从 Master 拉取数据。
总之，从 Master 拉取还是从 Slave 拉取由 Master 来决定。

早期的版本里，master挂了不会自动切换到slave里面去；
在RocketMQ4.5后引入了Dledger机制，通过Raft协议实现了自动切换，不过Dledger要求一个master至少要有2个slave，这样三个broker组成一个group。

image.png

Broker 每隔 30s 向 Name Server 发送心跳，Name Server 如果 120s 没有收到心跳，就会判断 Broker 宕机了。

image.png image.png

参考

RocketMQ架构原理
https://www.cnblogs.com/wlwl/p/14523315.html

图解 RocketMQ 的系统架构
http://www.uml.org.cn/zjjs/202202254.asp

RocketMQ 是如何使用dledger 模式保证故障自动恢复的？
https://blog.csdn.net/trntaken/article/details/105694384

分布式消息中间件）——RocketMQ架构
https://www.tpvlog.com/article/127

分布式消息中间件——RocketMQ生产部署
https://www.tpvlog.com/article/128