3. 常见架构：主从模式、分布式模式下的读写分离实现方式对比
读写分离是消息队列提升吞吐与可用性的核心手段。不同架构模式下的实现路径差异显著，故障表象与排查切入点也截然不同。本节从主从模式与分布式模式两个维度，对比 Kafka 与 RocketMQ 的读写分离实现方式。
3.1 主从模式下的读写分离
主从模式（Master-Slave）通常由一台 Master 节点承担写入，一台或多台 Slave 节点提供读取或冷备。该模式架构简单，但存在单点瓶颈与数据一致性问题。
核心特征：写入全量路由至 Master，读取可路由至 Slave；Slave 通过异步或同步复制从 Master 拉取数据。
3.1.1 RocketMQ 主从模式
RocketMQ 的 Broker 支持 Master 与 Slave 角色。Master 负责写入与拉取消息，Slave 仅作为读取节点或故障切换备机。
- 写入路径：Producer 始终连接 Master 节点，消息写入 CommitLog 并构建 ConsumeQueue。
- 读取路径：Consumer 默认从 Master 拉取；当 Master 负载过高或不可用时，自动切换至 Slave 读取。
- 数据同步：Slave 通过
HAConnection从 Master 异步拉取 CommitLog 数据，延迟通常在毫秒级。
| 对比维度 | RocketMQ 主从模式 | Kafka 主从模式 |
|---|---|---|
| 角色定义 | Broker 配置 brokerRole=ASYNC_MASTER / SYNC_MASTER / SLAVE | 每个 Partition 有 1 个 Leader 和多个 Follower |
| 写入节点 | 固定 Master Broker | Partition Leader |
| 读取节点 | 默认 Master，可配置 Slave 读取 | 默认 Leader，可配置 Follower 读取（Rack 感知） |
| 数据一致性 | 异步复制可能丢少量数据 | ISR 机制保证已提交数据不丢失 |
| 故障切换 | 手动或依赖 NameServer 感知 | Controller 自动选举新 Leader |
3.2 分布式模式下的读写分离
分布式模式将数据分片（Partition）分布在多个节点，每个分片有自己的 Leader 与 Follower。读写分离在分片粒度实现，具备更好的弹性与吞吐。
3.2.1 Kafka 分区级读写分离
Kafka 的每个 Partition 有 1 个 Leader 和多个 Follower。Leader 处理该分区的所有读写请求，Follower 仅从 Leader 同步数据。Kafka 2.4+ 引入 Follower 读取特性，允许 Consumer 从 Follower 拉取数据以分担 Leader 负载。
- 写入路径：Producer 根据分区策略将消息发送至对应 Partition 的 Leader。
- 读取路径：Consumer 默认从 Leader 拉取；通过
client.rack配置可优先从同一机架的 Follower 读取。 - 数据一致性：ISR（In-Sync Replica）机制保证只有同步副本参与 Leader 选举，已提交数据不丢失。
3.2.2 RocketMQ 分布式模式
RocketMQ 的分布式模式基于 DLedger（Raft 协议）实现自动选主与数据强一致。每个分片组（DLedger Group）包含多个节点，通过 Raft 选举产生 Leader 处理写入，Follower 提供读取。
- 写入路径：Producer 将消息发送至 DLedger Group 的 Leader 节点。
- 读取路径：Consumer 默认从 Leader 读取；Follower 可提供读取能力，但需客户端显式配置。
- 数据一致性：Raft 协议保证写入超过半数节点后才返回成功，强一致性。
故障排查提示：分布式模式下，读写分离故障常表现为“Follower 读取延迟大”或“Leader 负载不均”。排查时优先检查 ISR 列表（Kafka）或 DLedger 角色状态（RocketMQ），确认 Follower 是否处于同步状态。
3.3 两种模式对比总结
| 对比维度 | 主从模式 | 分布式模式 |
|---|---|---|
| 数据分片 | 无分片，所有数据在同一节点 | 分片存储，每个分片独立选主 |
| 写入吞吐 | 受限于单节点性能 | 随分片数线性扩展 |
| 读取扩展 | 依赖 Slave 节点数量 | 每个分片 Follower 均可提供读取 |
| 数据一致性 | 异步复制为主，可能丢数据 | ISR / Raft 保证强一致或最终一致 |
| 故障恢复 | 手动切换或依赖外部组件 | 自动选主，秒级恢复 |
| 运维复杂度 | 低，配置简单 | 较高，需管理分片与副本 |
| 典型场景 | 中小规模、低延迟敏感 | 大规模、高吞吐、高可用要求 |
故障排查关键点：主从模式下，Slave 读取延迟突增通常由复制链路阻塞引起，检查
HAConnection 状态与网络延迟。分布式模式下，Follower 读取失败多因 ISR 列表不全或 Raft 选举超时，优先查看 kafka.controller 日志或 DLedger 角色变更记录。