适用场景

MQ 堆积不可怕，可怕的是不知道为什么堆。堆积原因通常分四类：消费端处理慢、消费者数量不足、分区数不够、下游依赖超时。定位清楚再动作，否则加消费者可能带来乱序与重复消费。

配置步骤（消费端治理与容量基线）

# 消费端治理清单
1) 幂等：按业务主键去重表或 Redis 去重，TTL 覆盖最大重试周期
2) 限流：消费线程内对下游调用限流，避免压垮数据库
3) 超时：单条处理超时时间可控，超时进重试或死信
4) 死信：死信队列有告警与人工处理流程
5) 批处理：支持批量拉取 + 批量入库，提高吞吐
6) 可观测：消费速率、处理耗时、错误率、重试次数进监控
# 容量基线示例
订单消息：峰值 3000 条/秒，单条处理 20ms，消费线程 8 → 需 >= 3 个实例
大促预估：峰值 9000 条/秒 → 需提前扩容至 12 个实例并压测

关键参数与建议

  • 先量化：堆积量与增长速率，判断是突发还是持续
  • 分类定位：消费耗时、消费线程数、分区数、下游依赖耗时四查
  • 应急手段：扩消费者、扩分区、临时跳过非关键消息（需评估）
  • 顺序要求：需保序的业务不能随意扩分区，要先确认分区键
  • 幂等保障：扩消费者与重试会增加重复消费，消费端必须幂等
  • 下游保护：消费端要有限流与超时，避免压垮数据库
  • 长期治理：容量基线、堆积告警、定时任务与业务高峰错峰

容易踩的坑

  • 无幂等设计，扩容后重复消费造成脏数据
  • 死信队列没人看，问题消息长期堆积
  • 压测只测生产不测消费，大促时消费端崩
  • 批量入库未控制批量大小，一次提交几十万行
  • 监控缺消费耗时指标，出问题无法定位
  • 扩容后不缩容，平时资源浪费

验证与巡检

# 消费健康指标
# 1) 消费速率 vs 生产速率
# 2) 错误率与重试次数
# 3) 死信队列长度（应为 0 或有明确处理记录）

# 压测结论归档：峰值 TPS、P99 耗时、实例数
  • 巡检：死信为零或有处理记录、压测报告有效、容量基线与实例数匹配

小结

MQ 治理验收：堆积能在告警后 30 分钟内说清原因并给出处置，消费端支持幂等与限流，堆积不再靠人工盯着。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。