面试题：消息队列RocketMQ在日志处理系统中的数据一致性与故障恢复

Question

当日志处理系统中的RocketMQ出现节点故障时，如何保证已处理和未处理日志消息的数据一致性？详细说明从故障检测、消息重分配到数据恢复的完整机制及涉及的关键技术点。

Answer 1

故障检测

1. 心跳检测机制：RocketMQ 各个节点（如 Broker）之间会定时发送心跳包。当某个 Broker 在一定时间内未收到来自其他节点的心跳，就可初步判定对方出现故障。例如，默认心跳间隔为 30 秒，若超过 90 秒未收到心跳，可认为该节点故障。
2. 监控系统辅助：利用外部监控系统，如 Prometheus + Grafana，监控 RocketMQ 相关指标，如 Broker 的 CPU、内存使用率、网络流量等。当这些指标出现异常波动且持续一段时间，结合心跳检测结果，进一步确认节点故障。

消息重分配

1. NameServer 感知与通知：NameServer 负责管理 Broker 集群的元数据。当某个 Broker 节点故障时，其他正常 Broker 会通过心跳机制告知 NameServer。NameServer 随即更新集群元数据，将故障节点从可用列表中移除，并通知其他所有 Broker 节点。
2. 消息队列重新分配：
   • 每个 Topic 的消息队列分布在多个 Broker 上。故障发生后，NameServer 会根据负载均衡算法，重新计算消息队列在剩余正常 Broker 节点上的分布。例如，采用平均分配算法，将原本在故障 Broker 上的队列均匀分配到其他正常 Broker 上。
   • 客户端（生产者和消费者）会定期从 NameServer 获取最新的集群元数据，感知到队列重新分配后，调整自身的消息发送和消费逻辑，连接到新分配的队列。

数据恢复

1. 数据持久化保证：RocketMQ 使用刷盘机制保证数据持久化。有同步刷盘和异步刷盘两种方式。同步刷盘确保消息写入 Broker 的物理磁盘后才返回成功响应给生产者，而异步刷盘则是先将消息写入内存缓冲区，再异步刷盘到磁盘。故障发生后，由于数据已持久化，可从磁盘恢复。
2. HA 机制（高可用）：RocketMQ 支持主从架构（Broker 分为 Master 和 Slave）。当 Master 节点故障时，Slave 节点可切换为 Master 节点继续提供服务。切换过程中，从 Slave 节点加载持久化数据，确保消息不丢失。例如，在双活或多活架构下，通过快速切换，使得消息处理能够继续，已处理和未处理消息的数据一致性得以维持。
3. 事务消息机制（可选）：对于一些对数据一致性要求极高的场景，RocketMQ 支持事务消息。生产者发送半消息（Half Message），Broker 收到后暂不标记为可消费。生产者执行本地事务，根据事务执行结果向 Broker 发送 Commit 或 Rollback 指令。若生产者故障或未及时发送指令，Broker 会回查生产者事务状态。这样可保证消息要么被完整处理，要么不被处理，从而保证数据一致性。在故障恢复过程中，事务消息机制确保未处理完成的事务消息不会被错误消费，已处理完成的事务消息能正常提交，维持数据一致性。