转写任务在队列里积压到 3 万条，把消费者从 20 扩到 200，上游转写接口的 429 比例从 1% 涨到 40%，积压反而消化得更慢。
这类报错背后常见的原因有几处，逐个排除就行。消费者数量超过上游允许的并发配额；429 重试没有退避，失败任务立刻重回队列；预取数量过大，消息被锁在未确认状态；队列没有按优先级分层，重试任务抢占新任务。
上来先确认上游配额与当前并发
python -c "print('upstream concurrency 40, consumers 200')"再往下把消费者并发降到配额以内并开启退避
celery -A tasks worker --concurrency=40 --prefetch-multiplier=1 -Q asr然后开启延迟重试队列避免立即回灌
celery -A tasks worker -Q asr,retry --loglevel=info剩下的就是观察积压下降速率与 429 比例
redis-cli llen asr:pending恢复的判定其实很直接。429 比例回落到 2% 以内，积压条数以稳定速率下降，任务平均完成时间从 40 分钟缩到 12 分钟。
容易忽略的是，队列积压时加消费者只在上游有余量时有效，超过配额只会把重试风暴放大，先对齐配额再谈扩容。这类问题最好一次改到位，反复小改反而容易把原因搅混。