RocketMQ 高可用保障（HA）详细实战指南
这份文档讲的是“怎么让 RocketMQ尽量不停 + 尽量不丢 + 出事能自动/快速恢复”。
高可用不是一个开关，是一整套工程：架构冗余 + 正确配置 + 客户端容错 + 运维监控 + 演练。
目录
- 1. 先把目标说清楚：可用性 vs 不丢消息
- 2. HA 的分层思路（从外到内）
- 3. NameServer 高可用
- 4. Broker 高可用（核心）
- 4.1 经典 Master/Slave（4.x 常见）
- 4.2 DLedger（Raft 多副本 + 自动故障转移）
- 4.3 5.x Controller / 自动主从切换
- 4.4 跨机房/跨可用区（AZ）建议
- 5. 客户端侧容错（很多人忽略但很致命）
- 5.1 Producer：发送高可用
- 5.2 Consumer：消费高可用
- 6. 关键配置项建议（带理由）
- 7. 监控与告警（你不监控，就等于没 HA）
- 8. 故障演练清单（建议每季度至少一次）
- 9. 最小可落地的“生产推荐拓扑”
- 10. 常见坑（踩一个就能把你打回原形）
1. 先把目标说清楚：可用性 vs 不丢消息
高可用通常包含两类目标（经常被混在一起）：
- 服务可用性（Availability）
- Broker 挂一台，业务还能继续发/收（可能降级、延迟上升，但不停）
- 数据可靠性（Durability / 不丢消息）
- 机器断电/进程崩溃/磁盘异常，也要保证“已返回成功的消息”不丢
现实里这俩通常要做权衡：
- 同步刷盘 + 同步复制更不容易丢，但吞吐/延迟会更差
- 异步刷盘 + 异步复制性能好，但极端故障下可能丢“最后一小段”
所以你要先定清楚：你是金融级（宁慢不丢），还是互联网业务（可补偿，吞吐优先）。
2. HA 的分层思路（从外到内）
按层拆开看，HA 才能落地：
- 接入层 / 路由层：NameServer、（5.x 可能还有 Proxy）
- 存储层：Broker 的刷盘、复制、多副本、故障转移
- 客户端层：Producer 重试、故障规避；Consumer 重试、幂等、DLQ
- 运维层：监控、告警、容量、发布、演练
你会发现：
Broker 做得再强，客户端不重试、不幂等，一样能把系统整趴。
3. NameServer 高可用
NameServer 是路由中心，不存消息，但它对“新连接、新路由更新”很关键。
3.1 部署建议
- 至少 2 台 NameServer（建议 3 台更稳）
- 分散到不同物理机/不同 AZ（别全在一台宿主机）
- 客户端配置多个地址：
namesrvAddr=ip1:9876;ip2:9876;ip3:9876
3.2 客户端行为要点
- Producer/Consumer 会从 NameServer 拉路由并缓存；NameServer 短暂挂掉通常不影响已缓存路由的消息收发
- 但：如果你只有 1 台 NameServer，它挂了你就很难做路由更新、扩容、故障切换，恢复会很痛
4. Broker 高可用（核心）
Broker 决定了：消息存在哪、怎么复制、挂了怎么恢复。
4.1 经典 Master/Slave（4.x 常见）
这是最传统、最常见的部署模型。大方向是：
- 多个Master分摊负载（Topic 的队列分布在多个 Master 上）
- 每个 Master 配一个或多个Slave做备份（同机房/跨 AZ 视成本与网络而定）
4.1.1 多 Master（无 Slave）
优点：成本低、吞吐高
缺点：单 Master 挂了，它上面的队列不可写（直到恢复），可靠性一般
4.1.2 多 Master + 多 Slave（异步复制）
优点：吞吐好，挂主后可读（视配置）
缺点：主挂的瞬间可能丢最后一小段未复制的数据（看复制滞后）
4.1.3 多 Master + 多 Slave（同步双写 / 同步复制）
优点：更不容易丢消息（主从都写成功才算成功）
缺点：写延迟上升，吞吐下降，对网络抖动更敏感
经验：如果你真的对“不丢”敏感，同步复制 + 同步刷盘是最直接的思路，但要准备好吞吐下降。
4.2 DLedger（Raft 多副本 + 自动故障转移）
DLedger 的定位：用 Raft 做一致性复制，让 Broker 更像“有选主能力的多副本日志系统”。
典型价值：
- 多副本 commitlog，一般是3 副本（奇数）
- Leader 挂了能自动选举新 Leader（自动恢复写能力）
- 更接近“强一致复制”（具体一致性取决于配置与实现）
适用：
- 你需要更强的自动故障转移能力
- 你愿意付出更多机器和网络成本（多副本）
4.3 5.x Controller / 自动主从切换
RocketMQ 5.x 里常见的方向是：把“主从切换/控制面能力”抽出来，形成Controller（有的场景也会和 DLedger 思路结合）。
你可以把它理解成：
- Broker 专心做存储与读写
- Controller 负责集群状态、主从切换、选主等控制逻辑
- 目标是：故障时更自动、更快恢复写入
如果你在用 5.x，并且你的部署方案支持 Controller/自动故障转移模式，建议优先评估这一套（尤其是云原生/容器化环境）。
4.4 跨机房/跨可用区（AZ）建议
跨 AZ 是 HA 的“终极形态”之一，但成本也更高（网络 RTT、带宽、丢包都会影响同步复制）。
建议优先级（从易到难）：
- 同机房多实例 + 多盘冗余 + 快速自动拉起
- 同城双 AZ：Master/Slave 分 AZ（复制链路跨 AZ）
- 异地多活/双写（业务复杂度最大，通常需要业务侧强补偿）
实操建议：
- 同步复制跨 AZ：先压测网络抖动对延迟的影响
- 异步复制跨 AZ：更现实，但要接受极端情况下的少量丢失（或用业务补偿）
5. 客户端侧容错（很多人忽略但很致命）
5.1 Producer：发送高可用
你要做到的效果是：某个 Broker/某条链路坏了，Producer 自动绕开，尽量发到别处。
建议点：
- namesrvAddr 配多个
- 发送失败重试（同步/异步都要考虑）
- 合理设置：
retryTimesWhenSendFailedretryTimesWhenSendAsyncFailed
- 开启“故障规避/延迟容错”（不同版本叫法不同，核心是：把高延迟/失败的 broker 暂时踢出候选）
- 发送端一定要有日志与告警：失败率、超时率、分位延迟（P95/P99）
非常重要：Producer 侧要理解“发送成功”的语义：
- 如果是异步刷盘/异步复制，成功不代表“已在多副本落稳”。
- 真要“金融级不丢”，要配合 Broker 侧策略（同步刷盘 + 同步复制）一起上。
5.2 Consumer：消费高可用
Consumer 的高可用，目标是：某个消费者挂了，其他实例接管；某条消息失败，不要把整体拖死。
建议点：
- 一个消费组至少2 个实例（别单点）
- 使用集群消费（Clustering）进行负载分担
- 消费失败要有：重试策略 + DLQ（死信队列）
- 业务必须幂等（RocketMQ 默认更偏至少一次语义）
- 对“毒消息”要有隔离策略：
- 重试次数上限
- 进入 DLQ 后有处理入口（人工/自动补偿）
6. 关键配置项建议（带理由）
配置名不同版本可能略有差异，但核心思路一致。
6.1 Broker 刷盘策略（flushDiskType）
ASYNC_FLUSH：吞吐更高，极端断电可能丢最后一小段SYNC_FLUSH：更安全，但延迟更高
建议：
- 核心链路（资金/账务/关键订单）：优先
SYNC_FLUSH - 非核心链路（日志/埋点/可补偿事件）：
ASYNC_FLUSH常见
6.2 Broker 复制角色（brokerRole）
常见选项：
ASYNC_MASTER：异步复制 masterSYNC_MASTER：同步复制 masterSLAVE：从节点
建议：
- 要更稳：
SYNC_MASTER - 要吞吐：
ASYNC_MASTER
6.3 线程池与快速失败（防雪崩）
当下游故障时，Broker 线程池可能堆积导致雪崩。
建议关注“快速失败”/队列长度/线程池大小等配置，让系统在压力异常时更快返回错误，从而触发上游重试与熔断，而不是把自己拖死。
6.4 存储与磁盘
- CommitLog 强依赖磁盘顺序写吞吐：别用共享盘/垃圾盘糊弄
- 磁盘 80% 以上就是事故前夜（清理策略/扩容必须提前）
- 建议：
- commitlog 盘与系统盘分离
- RAID/云盘级别的可靠性选型要清楚（别只看价格）
7. 监控与告警（你不监控，就等于没 HA）
必须监控的“生死指标”：
7.1 Broker 维度
- Broker 存活（心跳、进程、端口）
- 磁盘使用率（尤其是 store 目录）
- 复制滞后（主从同步延迟、in-sync 状态）
- 写入/读取 TPS、延迟（P95/P99）
- 线程池队列堆积、拒绝数
7.2 Topic/Group 维度
- 消费堆积（lag）
- 重试量、DLQ 增长
- 消费失败率、消费耗时分位数
7.3 NameServer / Controller（如有）
- 节点存活
- leader 状态（如果是 controller/raft 集群）
- 路由更新时间异常
告警建议：
- “硬阈值 + 趋势阈值”组合（比如磁盘增长速度异常也要报警）
- 不要只报警“挂了”，要报警“快挂了”
8. 故障演练清单（建议每季度至少一次）
你可以按这个顺序做演练：
- NameServer 挂一台
- 预期：消息收发基本正常；路由更新能力下降但不致命
- Broker Master 挂掉
- 预期：
- 有自动切换能力：写入恢复（可能有短暂抖动）
- 无自动切换：该 master 上的队列不可写，业务侧要容错/降级
- Slave 挂掉/复制链路中断
- 预期：集群可用性仍在，但可靠性下降（告警要响）
- 磁盘写满/写慢（最真实的事故之一）
- 预期：写入延迟飙升、失败率上升；快速失败与上游熔断是否工作
- 消费者整体不可用（全部停）
- 预期：堆积上涨；恢复后逐步追赶；没有把 Broker 打爆
演练必须产出：
- 故障发生时间线
- 发现时间（MTTD）
- 恢复时间（MTTR）
- 根因与改进项
9. 最小可落地的“生产推荐拓扑”
如果你想用最少机器做一个“还算靠谱”的生产 HA：
方案 A：经典 Master/Slave（成本相对低）
- NameServer：2~3 台
- Broker：至少 2 个 Master，每个 Master 配 1 个 Slave（Master/Slave 跨 AZ 更好）
- 关键 Topic：SYNC_MASTER + SYNC_FLUSH（或至少 SYNC_MASTER）
方案 B：DLedger / Controller（自动故障转移更强）
- NameServer：2~3 台
- Controller（如你的架构需要）：奇数个节点（常见 3）
- Broker：按多副本/自动切换方案部署（通常 3 副本更稳）
- 配套：完善监控告警 + 演练
10. 常见坑（踩一个就能把你打回原形）
- 只有 1 台 NameServer
- Broker 全在同一台宿主机/同一 AZ（看似多副本，实际同生共死）
- 异步刷盘 + 异步复制，还自信“绝对不丢”
- 消费者不幂等：重试导致重复扣款/重复发货
- DLQ 没人管：死信越积越多，最后变成“系统性欠账”
- 磁盘不监控/不扩容：写满直接宕机
- 不演练：事故发生才第一次验证方案
最后一句话
RocketMQ 的 HA 不是靠“部署多几台”就完事了，真正靠谱的组合是：
多 NameServer + Broker 多副本/可切换 + Producer 重试与故障规避 + Consumer 幂等与 DLQ + 监控告警 + 定期演练
把这套跑顺，你的 RocketMQ 才算真的“高可用”。
)
