队列消费积压事件工作流

把消费积压当独立事件分诊：区分生产端洪峰与消费端停摆，再决定扩容、降载还是排水。

目标

消费积压常被当成一个问题处理，但消费端停摆与生产端洪峰是截然相反的两种病：前者要修 bug，后者要扩容或降载。先读积压曲线的形状再决定动哪半边系统；排水时还要保护下游——把积压压缩倾泻到数据库，是二次事故的标准配方。

步骤要点

读积压曲线形状：阶跃（消费停摆）、爬升（生产洪峰）、锯齿（消费速率长期低于生产速率）。
阶跃形态查消费端健康：错误、重启、单条处理耗时，找到崩溃或毒消息循环的具体故障。
爬升形态查生产与下游：区分洪峰是合法流量还是重试风暴，并确认下游能吸收更快的消费速率。
带保护地排水：扩容消费端同时对下游限速，非关键主题跳过或进死信，优先排重要的积压。
修根因后重新校准告警：阈值要能区分合法洪峰与故障，避免下次洪峰再误打页。

排错提示

扩容排水把下游打挂是没做限速，排水计划必须包含下游速率上限与主题优先级；毒消息让消费者反复重启要靠死信隔离而不是无限重试；同一洪峰反复误告警说明阈值没复盘，每次积压事件结束都要重写“多算正常、多算故障”的界线。

适用边界

积压形状诊断依赖分钟级监控粒度，过粗的采集会掩盖阶跃与锯齿的差别；部分队列无原生死信，需要应用层实现隔离队列。

代码示例

lag shapes (5-min buckets):
  step:      0,0,0,41200,41300,41300  -> consumer stopped
  ramp:      0,900,3100,8400,17000    -> producer surge
  sawtooth:  0,8K,2K,9K,3K,10K        -> consumer < rate

step: consumer restart x 14, poison msg loop
  fix: dead-letter the poison message, patch handler
ramp: marketing email blast (legit)
  fix: scale consumers 4->12, cap at db limit (200/s)
        skip analytics topic (non-critical)