第 16 章：刷盘与主从复制

这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 刷盘决定单机数据在机器故障下的持久性，复制决定多机数据在节点故障下的可用性。RocketMQ 的可靠性不是单个开关，而是“客户端确认 + 刷盘策略 + 复制策略 + 故障切换 + 运维流程”的组合结果。

16.1 可靠性层次

Producer receive OK
  -> Broker memory
  -> local disk
  -> replica memory
  -> replica disk

每前进一层，抗故障能力增强，延迟和成本也增加。

16.2 同步刷盘与异步刷盘

异步刷盘并非没有价值。配合同步复制和多副本，可以在性能与可靠性之间取得平衡。

选择建议：

1. 交易、支付、账务类事件优先高可靠配置；
2. 行为日志可接受较低成本配置；
3. 性能结论必须基于自身磁盘和压测；
4. 任何模式都要有业务对账；
5. 不要只看参数名，要确认版本语义。

16.3 复制模式

传统主从模式常见配置：

同步复制流程：

master append message
  -> flush local
  -> replicate to slave
  -> slave persist
  -> slave ack
  -> master return success

异步复制流程：

master append message
  -> return success
  -> replicate later

16.4 高可用架构演进

常见模式：

1. 主从读写分离；
2. DLedger 自动切换；
3. Controller 模式；
4. 5.x Proxy 与计算存储分离；
5. 云托管多可用区部署。

演进逻辑：

手工运维
  -> 自动选主
  -> 元数据中心化
  -> 计算接入层与存储层解耦

不同模式的部署要求、客户端兼容性和恢复行为不同，不能只比较功能名。

16.5 副本一致性

关注三个位点：

故障切换时必须处理：

1. 未复制到新主的尾部消息；
2. 消费位点是否超过数据位点；
3. 老主恢复后是否脑裂；
4. 客户端路由何时更新；
5. 事务和定时消息状态；
6. 运维操作审计。

16.6 脑裂与 fencing

脑裂指两个节点同时认为自己是主。常见防线：

1. Controller 或 DLedger 多数派仲裁；
2. epoch 或 term 递增；
3. 共享磁盘锁；
4. 客户端路由校验；
5. 网络分区时禁止双写；
6. 恢复流程强制对齐位点。

生产环境不应只依赖人工确认角色，要依赖仲裁机制和版本 fencing。

16.7 跨可用区部署

典型拓扑：

zone A: broker-a-master, broker-b-replica
zone B: broker-a-replica, broker-b-master

收益：

1. 单可用区故障可恢复；
2. 流量分布更均衡；
3. 副本不集中在一个故障域。

代价：

1. 同步复制延迟增加；
2. 带宽成本增加；
3. 运维复杂度提高；
4. 机房间网络抖动影响写入；
5. 需要验证 NameServer 与客户端路由策略。

16.8 监控与演练

指标：

broker_flush_latency_ms
replica_sync_latency_ms
replica_diff_bytes
broker_role
broker_epoch
unsynced_replica_count
master_changes_total
disk_usage_ratio

必做演练：

1. kill Broker 进程；
2. 宿主机断电重启；
3. 断开从节点网络；
4. 机房间网络抖动；
5. 磁盘故障；
6. 主从位点不一致恢复；
7. 客户端重连和路由更新。

16.9 常见问题

本章小结

刷盘和复制决定消息持久化边界。同步刷盘增强单机断电能力，同步复制增强节点故障能力，自动选主增强可用性，但都伴随延迟与成本。生产设计要明确业务容忍度，压测验证，并持续监控副本差距和演练故障恢复。

思考题

1. 异步刷盘最怕什么故障？
2. 同步复制能防止磁盘损坏导致的丢失吗？
3. 为什么切主可能造成尾部消息差异？
4. 脑裂为什么必须依赖仲裁和 fencing？
5. 跨可用区部署的主要代价是什么？