RocketMQ 生产检查清单

适用 RocketMQ 4.9 / 5.3 / 5.5。4.x 与 5.x 的部署形态、Controller 和客户端参数有差异，默认值以对应版本官方文档为准。 只列不做会丢数据、会不可用、会查不出故障的动作；机制解释见本目录各篇正文。

上线前

• [ ] 先写死 RPO/RTO 再选复制模式：核心链路要求 RPO=0 就不能用 ASYNC_MASTER，要用 SYNC_MASTER 或 DLedger/Controller；Controller 保持 enableElectUncleanMaster=false（5.x 默认）。上线前做过一次 kill Master 演练，记录从停写到恢复的实测 RTO。
• [ ] 刷盘策略与 RPO 对齐：flushDiskType=ASYNC_FLUSH（默认）宕机最多丢约 500ms 写入；核心业务用 SYNC_FLUSH，或 ASYNC_FLUSH + SYNC_MASTER。syncFlushTimeout=5000（4.9/5.x），Slave 不可用时 SYNC_MASTER 返回失败，不会静默降级成异步。
• [ ] Queue 数按目标消费者数的 2 倍规划：Queue 只能增不能减，消费者数不要超过 Queue 数。顺序消费单独建组、单独评估 Queue 数，并显式设置 maxReconsumeTimes（部分版本顺序消费默认接近不限）。
• [ ] 磁盘水位和保留期有告警：fileReservedTime=72（小时）、deleteWhen=04；75% 开始删过期文件、85% 强制清理、90% 拒写。75% 前告警；积压接近保留期时先扩消费，不要靠调大保留期掩盖。
• [ ] 重试与 DLQ 的边界定好：并发消费默认重试 16 次、累计约 4 小时 46 分后进入 %DLQ%<consumerGroup>；DLQ 与普通消息同保留期，默认 72 小时。指定责任人，明确控制台重发或搬运消费者两条路径。
• [ ] ACL 和网络边界先收紧：aclEnable=true，plain_acl.yml 按应用分配 PUB/SUB 最小权限，admin: true 只给运维；9876/10911/8081 不暴露公网。ACL 只管授权，传输加密另配 TLS。

运行中

• [ ] 复制状态：mqadmin brokerStatus 与 getBrokerRuntimeInfo 看主从连接和 slaveFallBehind；SYNC_MASTER 下 Slave 追不上会让发送等满 syncFlushTimeout=5000 后失败，表现为 RT 升高、错误率上升。
• [ ] 磁盘与刷盘：getBrokerRuntimeInfo 看磁盘使用率、PageCache、刷盘位置；75/85/90 三档都要有告警和对应 runbook。
• [ ] 消费进度与 Rebalance：consumerProgress 看每 Queue 的 broker offset/consumer offset/diff，部分版本加 -s 看归属；Rebalance 默认 20s 一次，频繁触发先查 Consumer 心跳、GC、网络。
• [ ] DLQ 与顺序队列：topicStatus -t "%DLQ%<consumerGroup>" 看 maxOffset 是否增长；顺序消费看单 Queue 是否停住——坏消息会阻塞整条队列，达到上限前放行不了。

故障时

• [ ] 积压（diff 持续上涨） → consumerProgress、topicStatus、clusterList → Consumer TPS 正常是容量不足，先扩到 Queue 数；TPS 低是下游慢；TPS 为 0 是卡住。不要先重启 Consumer，Rebalance 会让积压更重。
• [ ] 消息丢失 → queryMsgByKey/queryMsgById、topicStatus、consumerProgress → 查不到且发送失败是生产端；查不到但发送成功查 Broker 刷盘和路由；查得到但位点已越过查消费端异常吞噬；超过 72h 是保留期清理。生产端用同步发送 + 重试 + outbox，事后按业务单号对账。
• [ ] 消费卡住（不报错但 diff 不降） → consumerConnection、jstack <pid> 搜 ConsumeMessageThread、jstat -gcutil <pid> 1000 → 线程池被慢调用占满、DB 锁等待、Full GC 或顺序队列队头阻塞。不要用空消息替换失败消息放行。
• [ ] 磁盘到 90% 拒写 → getBrokerRuntimeInfo 看磁盘水位、df -h、Broker 日志 → 先清理过期文件/扩盘/迁移 Topic；不要手工删 commitlog。85% 的强制清理可能删掉未消费的过期数据。
• [ ] 误用位点重置处理 DLQ → resetOffsetByTime 只重置原 Topic 上该消费组的位点，不搬运 %DLQ% 消息 → 重投要走控制台重发，或订阅 %DLQ%<consumerGroup> 的搬运消费者；重置会让整组回退并产生大量重复，先停消费、确认幂等。