如何实现 RocketMQ 高可用？

如何实现 RocketMQ 高可用？

如何实现 RocketMQ 高可用？

在 「RocketMQ 由哪些角色组成？」 中，我们看到 RocketMQ 有四个角色，需要考虑每个角色的高可用。

RocketMQ 集群

🦅 1. Producer

1. Producer 自身在应用中，所以无需考虑高可用。
2. Producer 配置多个 Namesrv 列表，从而保证 Producer 和 Namesrv 的连接高可用。并且，会从 Namesrv 定时拉取最新的 Topic 信息。
3. Producer 会和所有 Broker 直连，在发送消息时，会选择一个 Broker 进行发送。如果发送失败，则会使用另外一个 Broker 。
4. Producer 会定时向 Broker 心跳，证明其存活。而 Broker 会定时检测，判断是否有 Producer 异常下线。

🦅 2. Consumer

1. Consumer 需要部署多个节点，以保证 Consumer 自身的高可用。当相同消费者分组中有新的 Consumer 上线，或者老的 Consumer 下线，会重新分配 Topic 的 Queue 到目前消费分组的 Consumer 们。
2. Consumer 配置多个 Namesrv 列表，从而保证 Consumer 和 Namesrv 的连接高可用。并且，会从 Consumer 定时拉取最新的 Topic 信息。
3. Consumer 会和所有 Broker 直连，消费相应分配到的 Queue 的消息。如果消费失败，则会发回消息到 Broker 中。
4. Consumer 会定时向 Broker 心跳，证明其存活。而 Broker 会定时检测，判断是否有 Consumer 异常下线。

🦅 3. Namesrv

1. Namesrv 需要部署多个节点，以保证 Namesrv 的高可用。
2. Namesrv 本身是无状态，不产生数据的存储，是通过 Broker 心跳将 Topic 信息同步到 Namesrv 中。
3. 多个 Namesrv 之间不会有数据的同步，是通过 Broker 向多个 Namesrv 多写。

🦅 4. Broker

1. 多个 Broker 可以形成一个 Broker 分组。每个 Broker 分组存在一个 Master 和多个 Slave 节点。 Master 节点，可提供读和写功能。Slave 节点，可提供读功能。 Master 节点会不断发送新的 CommitLog 给 Slave节点。Slave 节点不断上报本地的 CommitLog 已经同步到的位置给 Master 节点。 Slave 节点会从 Master 节点拉取消费进度、Topic 配置等等。
2. 多个 Broker 分组，形成 Broker 集群。 Broker 集群和集群之间，不存在通信与数据同步。
3. Broker 可以配置同步刷盘或异步刷盘，根据消息的持久化的可靠性来配置。

🦅 总结

目前官方提供三套配置：

2m-2s-async

brokerClusterName	brokerName	brokerRole	brokerId
DefaultCluster	broker-a	ASYNC_MASTER	0
DefaultCluster	broker-a	SLAVE	1
DefaultCluster	broker-b	ASYNC_MASTER	0
DefaultCluster	broker-b	SLAVE	1

2m-2s-sync

brokerClusterName	brokerName	brokerRole	brokerId
DefaultCluster	broker-a	SYNC_MASTER	0
DefaultCluster	broker-a	SLAVE	1
DefaultCluster	broker-b	SYNC_MASTER	0
DefaultCluster	broker-b	SLAVE	1

2m-noslave

brokerClusterName	brokerName	brokerRole	brokerId
DefaultCluster	broker-a	ASYNC_MASTER	0
DefaultCluster	broker-b	ASYNC_MASTER	0

相关的源码解析，胖友可以看看 《RocketMQ 源码分析 —— 高可用》 。