先立仪表盘，再谈调优
调优的前提是知道哪里疼。MQ 的监控指标分成三块看板，缺一块就是盲区：发送侧、Broker 侧、消费侧。
| 看板 | 核心指标 | 危险信号 |
|---|---|---|
| 发送侧 | 发送 TPS、发送耗时 P99、发送失败率 | P99 持续大于 50ms、失败率大于 0.1% |
| Broker 侧 | 磁盘水位、写入 TPS、请求排队、主从延迟 | 磁盘大于 80%、主从延迟持续增长 |
| 消费侧 | 消费 TPS、积压量（lag）、消费耗时 P99、重试量、死信量 | lag 持续上涨、死信大于 0、重试率突增 |
lag 要看两个数，不是一个
积压量（lag）单看数字会误判：大 Topic 积压 10 万条可能 1 分钟追平，小 Topic 积压 5000 条可能要一天。正确的姿势是同时看积压量和追平时间：
追平时间(秒) ≈ 当前积压条数 / (消费TPS - 生产TPS)告警按追平时间设：大于 5 分钟告警，大于 30 分钟升级。这个口径把「正常洪峰的临时积压」和「消费能力塌了的真故障」自然区分开——前者追平时间短，后者追平时间发散。
发送参数调优清单
- 可靠性三件套（第 6 篇定过的基调）：Kafka acks=all + retries 合理值；RocketMQ 同步发送 + 默认重试 2 次；
- 吞吐取舍：Kafka 业务消息 linger.ms 5-20ms、batch.size 64KB-256KB；延迟敏感场景 linger.ms 回 0；
- 超时分级：发送超时要小于接口超时，别让一次 MQ 调用拖垮整个请求；
- 消息体积：单条控制在几 KB 到 128KB，大附件传引用不传内容。
消费参数调优清单
- 消费线程数：并发消费线程按「下游承受力」定，不是越大越好——下游写库能力 2000 TPS，消费开 200 线程只会把库打挂；
- 批量拉取：Kafka max.poll.records 调到单批处理时间稳定在秒级以内；RocketMQ 调整 pullBatchSize；
- 幂等缓存：去重表前加一层本地或 Redis 去重缓存，挡掉绝大多数重复，落库校验做兜底；
- 超时与心跳：Kafka max.poll.interval.ms 大于单批最慢耗时，心跳配比按第 14 篇口诀。
两个常见调优误区
误区一：消费慢就加线程。老王第一次调优把消费线程从 20 加到 200，TPS 只涨了一成，下游数据库连接池先爆了。消费 TPS 的天花板九成在下游（数据库、外部接口），先量下游再动线程。
误区二：所有 Topic 无脑开压缩攒批。压缩是 CPU 换带宽的交易，日志类大文本稳赚，小 JSON 消息可能压缩比不到 2 还搭上 CPU。按 Topic 画像分开配置。
值班手册模板
- lag 追平时间大于 5 分钟 → 告警，值班先看消费 TPS 与下游健康；
- 死信量大于 0 → 当天处理，重放前过幂等检查；
- 发送失败率大于 0.1% → 查 Broker 水位与网络分区；
- 磁盘大于 80% → 清理过期段或扩容，低于 20% 剩余时 Broker 进入保护；
- 每月一次：告警阈值复盘 + 容量趋势预测。
小结
监控三看板（发送、Broker、消费），lag 双口径（积压量加追平时间），调优先量下游再动参数。参数清单是静态的，业务流量是活的——阈值定期复盘，比一次调到位更重要。
工具箱配齐了，下一篇把理论收进真实业务：实战场景集——订单超时、秒杀、数据同步、最终一致，四个场景的完整方案串讲。
评论 (0)