一个让我困惑了很久的问题
刚开始学 RocketMQ 的时候，我看文档上说它支持主从架构，Master 负责写，Slave 负责读。但当我追问"如果 Master 挂了怎么办"的时候，得到的回答是：需要人工介入，修改配置，重启节点。
与此同时，Kafka 在同样的问题上给出的答案是：自动切换，无需人工干预。
这让我产生了一个疑问：同样是分布式消息队列，为什么一个需要人工恢复，另一个可以自动完成？ 这不是运维工具好不好用的问题，而是底层架构设计层面的差异。
要回答这个问题，需要从两个系统的协调机制、存储模型、消息投递机制和高级特性四个维度去拆解。这篇文章就是我对这次对比的整理，也顺便把 RocketMQ 传统主从为什么不能自动切换这件事讲清楚。
协调机制：KRaft vs NameServer
Kafka 的演进：从 ZooKeeper 到 KRaft
Kafka 早期的集群管理依赖 ZooKeeper。Broker 注册、Controller 选举、分区 Leader 选举，这些职责都由 ZooKeeper 承担。但 ZooKeeper 逐渐成为了 Kafka 扩展性的瓶颈------当分区数量超过 10 万时，ZooKeeper 的开销和限制开始跟不上 Kafka 的增长。
于是 Kafka 社区在 KIP-500 中引入了 KRaft（Kafka Raft）协议。KRaft 的核心思路是把元数据管理的责任从 ZooKeeper 收回到 Kafka 自己内部，用一个内置的 Controller Quorum 来管理元数据日志。
Apache Kafka 4.0 已经默认运行在 KRaft 模式下，完全移除了对 ZooKeeper 的依赖。这不仅仅是"少部署一个组件"的问题，它改变了整个集群的管理模型。
KRaft 中的 Controller Quorum 节点数为奇数且大于等于 3，最多容忍 (n/2 - 1) 个节点失败，领导者选举依赖 Raft 协议。这里有一个值得注意的工程细节：经典 Raft 的日志复制是推模式（Leader 主动推送给 Follower），而 KRaft 改成了拉模式（Follower 主动拉取）。这个调整的目的是把一致性检查放在 Leader 端，同时更快地让新节点完成 bootstrap。
RocketMQ 的选择：去中心化的 NameServer
RocketMQ 走的是完全相反的路子。NameServer 是一个极轻量的路由注册中心，源码只有八个类、不到 1000 行代码。它的设计理念是：集群节点之间无任何信息交互。
工作流程很直接：
- NameServer 启动后监听 TCP 端口，集群多节点之间无任何信息交互，等待 Broker、Producer、Consumer 连接。
- Broker 启动后，每隔 30 秒向所有 NameServer 发送心跳命令，心跳包中包含 Topic 配置信息和路由信息。
- NameServer 收到心跳后，将路由信息保存在本地 HashMap 中，使用读写锁（ReentrantReadWriteLock）控制并发更新。
- NameServer 定时任务每隔 10 秒扫描存活 Broker 连接，如果某个连接的最后更新时间与当前时间差值超过 2 分钟，则断开此连接。
- Producer 和 Consumer 从 NameServer 获取路由信息后，直接与 Broker 建立连接进行通信。
这里的关键差异是： NameServer 节点之间不进行数据同步，每个 NameServer 独立维护自己接收到的路由信息。这意味着，如果某个 Broker 向 NameServer A 发送了心跳但还没向 NameServer B 发送，短暂时间内两个 NameServer 看到的路由信息可能不一致。但因为客户端会轮询多个 NameServer，且 Broker 每 30 秒就会向所有 NameServer 发送心跳，这个不一致窗口非常短。
RocketMQ 这样设计的目的很明确：用最终一致性换取极低的运维成本和极强的水平扩展能力。 NameServer 无状态、可随意增删，不需要像 ZooKeeper 那样维护复杂的选举和同步机制。
如果从 CAP 理论的视角来看，Kafka 的 KRaft 更偏向 CP（一致性优先），Controller Quorum 需要在元数据层面达成共识后才能对外服务；而 RocketMQ 的 NameServer 更偏向 AP（可用性优先），节点之间不通信，即使某个 NameServer 挂了，其他节点仍然可以独立提供服务，只是路由信息可能短暂不一致。这两种选择没有绝对的对错，取决于业务对元数据一致性的容忍度。
我踩过的坑是：最开始我以为 NameServer 的"无通信"是一个设计缺陷，觉得"多个节点之间不同步数据，那不一致怎么办？"后来才理解，对于路由信息这种"最终会一致"的数据来说，维护强一致性所需的通信成本远大于它带来的收益。Broker 每 30 秒发送一次心跳，这个频率在工程上已经把不一致窗口压缩到了可接受的范围。这与 ZooKeeper 的 ZAB 协议形成了鲜明对比------ZAB 需要维护一个强一致的元数据视图，代价是引入了外部依赖和运维复杂度。
存储模型：CommitLog + ConsumeQueue vs Partition + Segment
RocketMQ：日志文件 + 索引表的设计
RocketMQ 的存储采用 CommitLog + ConsumeQueue 的两层结构。
所有 Topic 的消息都混合写入一个 CommitLog 文件。CommitLog 默认每个文件 1GB，文件名以起始偏移量命名，保证消息顺序写磁盘。这种全局顺序写的设计，使得即使在 Topic 数量很多（几千个）的情况下，磁盘 IO 也不会变得零散。
ConsumeQueue 是消费索引，按 Topic 和队列 ID 组织，存储消息在 CommitLog 中的偏移量、消息大小等元信息，用于消费者快速定位消息。可以把这理解为数据库"主表 + 索引表"的设计：CommitLog 是主表，存储完整消息；ConsumeQueue 是索引，指向消息在 CommitLog 中的位置。
Kafka：分区独立的日志文件
Kafka 以 Partition 为基本存储单元。每个 Partition 在磁盘上对应一个日志文件夹，按 Segment 拆分，默认 1GB 一个 Segment。每个 Segment 包含 .log（数据）、.index（偏移量索引）、.timeindex（时间戳索引）三类文件。Kafka 的索引采用稀疏索引，每隔 4KB 消息才写一个索引项。
两种存储模型的核心差异在于：
RocketMQ 的 CommitLog 是全局顺序写，所有 Topic 的消息共享一组文件。这意味着写入性能与 Topic 数量无关。Kafka 的每个 Partition 独立写一个文件，Topic 和 Partition 数量增多时，磁盘 IO 会变得零散，写入性能可能下降。这是 RocketMQ 在电商、金融等 Topic 数量较多的场景中比 Kafka 更受欢迎的一个重要原因。
Kafka 的存储模型在流处理场景中更有优势：每个 Partition 独立管理，方便并行消费和水平扩展。而 RocketMQ 的 ConsumeQueue 索引在消息回溯、按时间戳查询等场景中提供了更灵活的定位能力。
消息投递机制：可靠性与吞吐量的取舍
RocketMQ 的刷盘策略支持同步刷盘（消息写入即持久化，不丢数据）和异步刷盘（先存内存，批量刷盘，性能更高），可按 Topic 配置，满足核心业务和非核心业务的差异化需求。
Kafka 主要依赖操作系统的 PageCache 进行异步刷盘，吞吐量极高，但在 Broker 宕机时存在数据丢失风险（可通过 acks=all 配置解决，但需牺牲性能）。
这里的设计取舍是：RocketMQ 给业务系统提供了颗粒度更细的可靠性控制能力；Kafka 默认追求极致吞吐，把可靠性的决策权交给生产者通过 acks 参数来控制。
高级特性：业务消息场景下的差异
RocketMQ 的高级特性
延迟消息：RocketMQ 内置了 18 个延迟级别，从 1s 到 2h 不等。消息在 Broker 端存储，到期后投递给消费者。这个特性在订单超时关闭、定时退款等场景中很常用。Kafka 没有原生的延迟消息支持，需要借助外部定时器或自己实现。
死信队列：消息消费失败后自动重试，默认每条消息重试 16 次，如果仍然失败，消息会进入死信队列，不再投递。这个机制适合处理消费者逻辑有 bug 或下游服务长时间不可用的情况。
消息过滤：RocketMQ 支持 Tag 过滤和 SQL92 属性过滤。Tag 过滤在 Broker 端进行，消费者订阅时指定 Tag，Broker 只推送匹配的消息，减少网络传输。
事务消息：RocketMQ 的事务消息支持二阶段提交能力，将二阶段提交和本地事务绑定，实现全局提交结果的一致性。生产者先发送半事务消息（消息被标记为"暂不能投递"），然后执行本地事务，根据本地事务结果决定提交或回滚。这一特性在分布式事务场景中非常实用。
Kafka 的定位
Kafka 的定位更偏向流处理平台。它原生面向高吞吐的流处理场景，在日志收集、实时数据分析、流式 ETL 等场景中有天然优势。
但这不意味着 Kafka 不能做业务消息------只是说 RocketMQ 在业务消息场景下提供了更多"开箱即用"的能力。事务消息、顺序消息、延迟消息、死信队列，这些都是业务系统常见的需求，用 Kafka 实现需要额外开发。反过来说，Kafka 在流处理生态（Kafka Streams、Kafka Connect）上的积累是 RocketMQ 不具备的。
选型判断
基于以上对比，我的理解是：
偏向 RocketMQ 的场景：业务系统需要事务消息、延迟消息、死信队列等高级特性；Topic 数量较多，需要保证写入性能的稳定性；需要更细粒度的刷盘策略控制；团队希望降低运维复杂度（NameServer 比 ZooKeeper 更轻量）。
偏向 Kafka 的场景：场景以流处理为主（日志收集、实时分析、数据管道）；需要极高的吞吐量；已有 Kafka 生态的积累（Connect、Streams）；团队对 ZooKeeper 或 KRaft 的运维有经验。
需要提醒的是 ：Kafka 4.0 移除 ZooKeeper 后，运维复杂度有所降低，这一点在选型时值得重新评估。但 KRaft 引入了 Controller Quorum 这个新的运维对象，它和 NameServer 的"无状态、无通信"设计仍然有本质差异。
回到开头那个问题
现在可以回答开头的问题了：RocketMQ 传统主从为什么不能自动切换？
因为 RocketMQ 的主从架构是基于 Broker 维度的，主从之间只做数据同步，没有内置的选举机制。当 Master 宕机时，Slave 只能继续提供读服务，但没有能力自动晋升为 Master 来接受写入。
而 Kafka 的自动切换能力来自两个机制：一是 Controller 负责管理分区 Leader 选举，二是 ISR（In-Sync Replicas）机制确保只有和 Leader 保持同步的 Follower 才有资格参与选举。当 Leader 副本宕机时，Controller 从 ISR 中选举新的 Leader，整个过程自动完成。
RocketMQ 并不是没有解决这个问题。 在 4.5 版本之后，RocketMQ 提供了 DLedger 模式，使用 Raft 算法实现了自动选主。如果 Master 节点出现故障，可以自动从 Slave 节点中选举出新的 Master 进行切换。DLedger 本质上是一个基于 Raft 协议的 CommitLog 存储库，通过 Raft 的选举和复制能力让 CommitLog 具备了自动选主和数据一致性保障。
但这个话题展开就太长了。我打算在下一篇文章里专门讲 DLedger 和 Raft：DLedger 到底做了什么，Raft 的选主和日志复制是怎么工作的，以及 RocketMQ 5.0 的 Controller 模式又做了哪些演进。如果你对这个方向感兴趣，可以先关注一下。
结尾
架构选型没有标准答案，只有适不适合当前场景的取舍。下一篇会从 DLedger 模式切入，把 Raft 的选主和日志复制讲清楚。
标签：RocketMQ Kafka 消息队列 分布式系统 Java后端