24｜从集群角度拆解RocketMQ的架构设计与实现

有一些疑问请教： 1.Dledger模式是多个独立的Master注册到NameServer，每个Master背后各自一个raft集群吗？ 2.Controller模式，文中提到Controller之间选主节点，这是通过选择完整性最高的Controller，在某个Master不可用之后，由Controller选择新的Master吗？

RocketMQ的三种部署模式 1. Master/Slave模式 分为Master、Slave两个角色，集群中可以有多个Master节点，一个Master节点可以有多个Slave节点。Master节点负责接收生产者发送的写入请求，将消息写入CommitLog文件，Slave节点会与Master节点建立连接，从Master节点同步消息数据（有同步复制和异步复制两种方式）。 消费者可以从Master节点拉取消息，也可以从Slave节点拉取消息。在RocketMQ 4.5版本之前，如果Master宕机，不支持自动将Slave切换为Master，需要人工介入。 优点 负载过高时，可以快速通过横向添加节点来扩容。 缺点 （1）Master节点宕机之后，不能自动将Slave节点切换为Master节点； （2）每个节点上都需要创建全量的Topic，存在性能瓶颈； 2. Dledger模式 为了解决主从架构下Slave不能自动切换为Master的问题，4.5版本之后提供了DLedger模式，使用Raft算法，如果Master节点出现故障，可以自动从Slave节点中选举出新的Master进行切换。 存在问题 （1）根据Raft算法的多数原则，集群至少有三个节点以上，在消息写入时，也需要大多数的Follower节点响应成功才能认为消息写入成功； （2）存在两套HA复制流程（个人认为是主从模式下一套、Dledger模式下一套），Dledger模无法利用RocketMQ原生的存储和复制能力。 3. DLedger Controller模式 RocketMQ 5.0以后推出了DLedger Controller模式，支持独立部署，也可以嵌入在NameServer中，Broker通过与Controller交互完成Master的选举。 在DLedger Controller模式中，数据的一致性可以通过参数inSyncReplicas配置来配置，不用向Dledger模式一样，需要要过半的Follower节点响应才算写入成功。 关于DLedger Controller模式详细信息可以参考 https://github.com/apache/rocketmq/blob/develop/docs/cn/controller/design.md