redis-cli LLEN callback:queue redis-cli LRANGE callback:queue 0 5
回调队列积压 40 万条，消费线程只有 2 个，最新一条延迟 6 小时，业务方以为回调丢了。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，消费端是单机双线程，一条平均处理 80 毫秒，理论吞吐只有 25 条每秒。高峰期每秒进来 60 条，缺口越拉越大。
这次卡住的地方就在「回调队列积压」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
处理上按这个顺序：先把消费并发提到 16 并压测单条耗时；按事件类型拆队列 慢事件单独消费；积压超阈值时扩容消费者；给队列长度和消费延迟加告警。
改完只确认一件事：队列长度在半小时内回落到三位数 消费延迟小于 1 分钟。