早上九点队列长度从 200 涨到 12 万，短信延迟最长的超过 4 小时。消费者进程 CPU 5%，日志停在昨天 23:41 的一条 debug 输出。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，消费进程只有一个，前一天排查问题时挂了断点没恢复。队列本身没有堆积告警，只有失败率监控，所以看不出问题。生产一条消息要调一次三方接口，单条耗时 300ms，本来也接近上限。
「发送队列堆积」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。改完顺手把文档补一句，省得下次自己重新推一遍。
ps -ef | grep sms_consumer redis-cli llen sms_queue kubectl scale deploy sms-consumer --replicas=6
监控和日志的时间要对上，时区不一致会多绕很大一圈。
具体做法是，先看消费者进程状态和最后一条日志时间；临时多开消费者 按分区并行消费；给队列长度和消息年龄加告警 阈值按分钟级；消费逻辑改成批量提交 降低单条开销。
最后用这个标准收尾，队列在 40 分钟内清空，消息平均延迟回到 10 秒以内，告警没有再触发。