适用场景

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

配置步骤（堆积定位与应急处置）

# 1) Kafka：查看消费组堆积
kafka-consumer-groups.sh --bootstrap-server broker1:9092 --describe --group order-consumer
# 关注：CURRENT-OFFSET、LOG-END-OFFSET、LAG

# 2) 分区与消费线程匹配度
# 消费线程数 <= 分区数，否则多余线程空转

# 3) 消费耗时定位
# 在消费日志中统计单条处理耗时分布（P50/P95/P99）

# 4) 下游依赖耗时
# 检查消费逻辑中调用数据库/接口的耗时，超时配置是否合理

# 5) 应急
#   - 先扩消费者（分区数足够时）
#   - 必要时临时降级非关键处理逻辑

关键参数与建议

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

容易踩的坑

  • 只看堆积数不看增长速率，误判为突发
  • 分区数不足，加消费者也无效
  • 扩消费者没考虑顺序要求，业务出现乱序
  • 消费端不幂等，重试后重复扣款
  • 无超时设置，一条慢消息卡住整个分区
  • 应急跳过消息没记录，数据丢失无从追溯

验证与巡检

# 堆积趋势采样（每 10 秒）
for i in 1 2 3 4 5 6; do
  kafka-consumer-groups.sh --bootstrap-server broker1:9092 --describe --group order-consumer | awk 'NR>1{s+=$6} END{print strftime("%H:%M:%S"), "lag=", s}'
  sleep 10
done

# 消费速率与生产速率对比，判断何时能追上
  • 巡检：LAG 趋势下降至 0、无分区偏移异常、消费耗时 P99 达标

小结

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

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