面试题：消息队列RocketMQ架构元数据管理与高可用性

Question

RocketMQ如何通过元数据管理机制来保障集群的高可用性？当Broker节点发生故障时，元数据管理是如何协同其他组件进行故障恢复和重新平衡的？

Answer 1

RocketMQ元数据管理保障集群高可用性

1. NameServer维护元数据：
   • NameServer是一个轻量级的元数据服务器集群，每个NameServer节点之间相互独立，不进行数据同步。它负责存储Broker、Topic等元数据信息。
   • Broker在启动时会向所有的NameServer节点注册自己的元数据，包括Broker名称、所属集群、IP地址、端口等信息。NameServer会将这些元数据持久化到本地文件系统（config/brokerregistry.json），以便在重启后快速恢复。
   • 生产者和消费者启动时，会从NameServer获取Topic的路由信息，包括Topic对应的Broker列表、Queue分布等元数据。这使得生产者和消费者能够知道消息应该发送到哪些Broker，以及从哪些Broker拉取消息，从而保障整个集群的正常运行。
2. 动态更新元数据：
   • 当Broker节点的状态发生变化（如新增、下线、网络故障恢复等）时，Broker会主动向所有NameServer节点更新自己的元数据。NameServer收到更新请求后，会更新内存中的元数据，并再次持久化到本地文件。
   • 生产者和消费者通过定时任务（默认30秒）从NameServer拉取最新的元数据，这样就能及时感知到Broker节点的变化，保证消息的正常发送和消费，从而保障集群的高可用性。

Broker故障时元数据管理协同故障恢复和重新平衡

1. 故障检测：
   • NameServer通过心跳机制检测Broker的存活状态。Broker会定时（默认30秒）向NameServer发送心跳包，NameServer如果在一定时间（默认120秒）内没有收到Broker的心跳，则认为该Broker发生故障。
   • 生产者和消费者在与Broker交互过程中，如果发现与Broker的连接异常断开，也会标记该Broker不可用，并等待下一次元数据更新。
2. 元数据更新：
   • NameServer在确认Broker故障后，会将该Broker从其维护的元数据中移除，并更新相关Topic的路由信息。例如，如果某个Topic原本有部分Queue分布在故障的Broker上，NameServer会重新计算该Topic的Queue分布，将故障Broker上的Queue分配到其他正常的Broker上。
   • NameServer将更新后的元数据持久化到本地文件，并等待生产者和消费者下一次拉取更新。
3. 生产者和消费者调整：
   • 生产者在感知到Broker故障和元数据更新后，会停止向故障Broker发送消息，并根据新的路由信息将消息发送到其他正常的Broker。
   • 消费者在感知到Broker故障和元数据更新后，会重新分配消费队列，从新的Broker上拉取消息进行消费。例如，采用Rebalance机制，消费者组内的各个消费者会根据新的Queue分布，重新分配消费任务，保证消息消费的均衡和完整性。
4. Broker故障恢复：
   • 当故障的Broker恢复后，它会重新向NameServer注册自己的元数据。NameServer会重新将该Broker纳入集群管理，并更新相关Topic的路由信息，将部分Queue重新分配到该恢复的Broker上。
   • 生产者和消费者在下次拉取元数据时，会获取到更新后的信息，从而恢复与该Broker的正常交互，整个集群重新达到平衡状态。