背景

CTGMQ 基于 RocketMQ4.9.x 最新版，开源版本目前除了 DLedger 模式，没有其它的高可用方案，所以我们为了满足多业务线和公有云的不同规格实例的高可靠、高可用需求以及成本关系，自己实现 Broker HA 的功能。

Master Slave架构

Master-Slave 模式是 RocketMQ 的默认模式，Master 节点负责接收消息，然后将消息同步到 Slave 节点。NameServer 是无状态的，只要 NameServer 集群有一个节点存活即可提供路由能力，客户端也会缓存路由信息，即使 NameServer 全部宕机，也不会影响到已有客户端的实例的消息发送和消费。在单 Master-Slave 部署模式下，Master 节点宕机，会导致集群不可用，需要人工干预修改 Slave 节点的配置，然后重启 Broker，这种方式会导致集群不可用的时间会比较长。如果是在多 Master-Slave 部署模式下，一个 Master Broker 节点宕机，消息仍然可以发送到另外的 Broker 组，但是对于有序消息的场景是不可接受的，导致定时消息、事务消息延迟或丢失等。

DLedger架构

DLedger 模式是 RocketMQ4.5 版本新增的高可用模式，基于 OpenMessaging 中的 Raft 存储库来实现，使其 Broker 具备选主能力。DLedger 模式下，每个 Broker 组都是一个 Raft 集群，该 Raft 集群至少包含三个节点，例如包含三个节点分别是 Leader、Follower1、Follower2。Leader 节点负责接收消息，然后将消息同步到 Follower1 和 Follower2 节点。如果 Leader 节点宕机，Follower1 节点会自动切换为 Leader 节点。
DLedger 模式的优点是保证了数据一致性，消息不丢失，即使一个 Broker 节点宕机，也不会影响集群的可用性，也能保证顺序消息的高可用。但该模式的缺点是成本会比较高，每个 Broker 集群都至少需要三副本及以上，而且对于流量比较大的场景，DLedger 模式的性能也不是很好，因为它遵循 Raft 多副本的 ACK 机制，另外无法使用 RocketMQ 原生的存储和复制的能力（ transientStorePool 和零拷贝）。

CTGMQ高可用架构

CTGMQ 高可用的设计基于 Master-Slave 模式，在未引入 Zookeeper、Etcd 等第三方组件的情况下，NameServer 通过 Raft 进行集群选主，将NameServer 作为控制节点，使得 Broker 在 Master-Slave 架构下具备自动主备切换的能力，解决单节点故障导致的集群不可用问题。

控制节点复用 NameServer 和 Broker 之间的注册心跳机制，周期性检测 Master Broker 节点的存活状态，如果心跳超时，NameServer 从剩余的 Slave 节点集合中选举出新的 Master Broker，然后将选举出的节点切换为 Master，同时将原来的 Master 节点切换为 Slave。为了保证消息的一致性和不丢失，Broker 遵循以下规则：

• Broker 的BrokerRole设置为SYNC_MASTER，整个集群为同步复制模式
• Broker 集群的同步副本集合数量达到2时，才能进行主备的切换
• 选举出的 Master 必须为同步副本集合中的节点
• Master Broker 保存 SlaveAckOffset 位点，在切换为 Slave 或节点宕机重新上线时，需要进行 CommitLog 的截断

在保证消息不丢失的前提下，为了满足集群的最大可用性，我们会对 Master Broker 的状态进行灵活的转换，Broker 的集群复制模式会随着同步副本的数量在 SYNC_MASTER 和 ASYNC_MASTER 之间切换。

结语

CTGMQ高可用架构解决了在Master-Slave架构下的顺序消息、定时消息以及事务消息的问题。不引入第三方组件，在Master Broker节点故障时进行自动主备切换，保证集群的高可靠、高可用。同时降低了成本，使得单个Broker组只需要两副本即可，性能也比DLedger模式好。