面试题：消息队列RocketMQ异步消息处理的高可用设计

Question

RocketMQ是如何设计来保证异步消息处理的高可用性的？如果出现节点故障，消息处理流程会如何调整？

Answer 1

RocketMQ保证异步消息处理高可用性的设计

1. 多副本机制
   • RocketMQ采用主从架构，每个Topic的每个队列（Queue）都有一个主副本和多个从副本。主副本负责处理读写请求，从副本实时从主副本同步数据。这种机制保证了即使主节点出现故障，从节点可以快速切换为主节点，继续提供服务，从而确保消息处理的高可用性。
2. NameServer集群
   • NameServer是RocketMQ的路由信息管理中心，它采用无状态的集群部署方式。每个NameServer都保存了完整的Broker、Topic等路由信息。生产者和消费者在启动时，会向所有的NameServer节点注册，并获取最新的路由信息。当某个NameServer节点出现故障时，其他NameServer节点仍然可以正常提供路由服务，不会影响消息的发送和消费。
3. Broker故障自动检测与转移
   • Broker之间通过心跳机制相互检测状态。当主Broker出现故障时，从Broker能够感知到，并向NameServer报告。NameServer会更新路由信息，将原主Broker对应的队列转移到新的主Broker（通常是从Broker中选举产生）。同时，生产者和消费者会通过定时拉取NameServer的路由信息，及时感知到这种变化，从而将消息发送或消费请求切换到新的主Broker上。
4. 刷盘策略
   • RocketMQ支持同步刷盘和异步刷盘两种策略。同步刷盘时，消息在写入主副本的内存后，会立即刷写到磁盘，确保消息不会因为系统故障而丢失，保证了数据的可靠性，进而保证了高可用性。异步刷盘则是将消息先写入内存，然后由后台线程异步刷盘，这种方式性能较高，但存在一定的数据丢失风险。在实际应用中，可以根据业务场景选择合适的刷盘策略来平衡性能和高可用性。
5. Dledger机制（4.5.0+版本）
   • Dledger是RocketMQ 4.5.0版本引入的一种基于Raft协议的分布式一致性算法。它为每个Topic的每个队列提供了强一致性保证。在Dledger组中，有一个Leader和多个Follower，消息首先发送到Leader，Leader通过Raft协议将消息同步到Follower，只有当大多数Follower成功同步后，Leader才会确认消息写入成功。这种机制不仅提高了消息处理的高可用性，还保证了数据的一致性。

节点故障时消息处理流程的调整

1. Broker主节点故障
   • 检测故障：从Broker通过心跳机制发现主Broker故障，立即向NameServer报告。
   • 选举新主：从Broker之间通过一定的选举算法（如基于Raft协议）选举出一个新的主Broker。
   • 更新路由：NameServer更新路由信息，将原主Broker对应的队列信息更新为新主Broker的地址。
   • 消息发送调整：生产者通过定时拉取NameServer的路由信息，感知到主Broker的变化，将后续的消息发送请求发送到新主Broker。
   • 消息消费调整：消费者同样通过定时拉取NameServer的路由信息，切换到从新主Broker上消费消息。对于已经发送到原主Broker但未被同步到从Broker的消息，在新主Broker选举出来后，会继续完成同步，确保消息不会丢失。
2. NameServer节点故障
   • 不影响已有连接：由于NameServer无状态，且生产者和消费者在启动时已经获取了完整的路由信息，所以在NameServer节点故障的短时间内，已建立连接的生产者和消费者仍然可以继续正常发送和消费消息。
   • 新连接处理：当有新的生产者或消费者启动，或者已有生产者和消费者需要更新路由信息时，它们会向其他正常的NameServer节点请求路由信息，从而保证新的消息发送和消费请求能够正常进行。同时，故障的NameServer节点恢复后，会自动同步其他NameServer节点的路由信息，重新加入集群。
3. 从Broker节点故障
   • 主从同步调整：主Broker会检测到从Broker故障，暂停向该从Broker同步数据。
   • 影响范围：从Broker故障一般不会影响消息的正常发送和消费，因为主Broker仍然可以正常提供服务。但是会影响消息的冗余备份，降低了数据的容灾能力。
   • 恢复处理：当从Broker恢复后，主Broker会将其故障期间累积的消息同步给它，使其重新跟上主Broker的进度，继续提供备份服务。