title: " AI排查队列积压 | Worker和死信" category: 人工智能 tags:

很多 AI 工作流最后都会引入队列。

比如：

批量摘要。
文档入库。
RAG 重新索引。
模型评测。
Webhook 重试。
异步生成报告。

队列一旦积压，用户看到的是：

任务一直处理中。
报告迟迟不出。
系统越来越慢。

队列问题很适合 AI 排查。

因为它需要同时看：

生产速度。
消费速度。
Worker 状态。
失败重试。
死信队列。
模型 API 耗时。
数据库写入。

1. 队列积压先看四个数

入队速率。
出队速率。
失败率。
最老任务等待时间。

只看队列长度不够。

队列长度 1000 不一定危险。

如果消费很快，可能正常。

最危险的是：

队列长度持续上升。
最老任务越来越老。
失败重试越来越多。

2. 给 AI 的队列排错包

【现象】
- 哪个队列：
- 当前长度：
- 最老任务等待时间：
- 影响业务：

【指标】
- 入队速率：
- 出队速率：
- 失败率：
- 重试次数：
- dead letter 数量：

【Worker】
- worker 数量：
- worker 日志：
- CPU/内存：
- 最近重启：

【任务】
- top task_type：
- 单任务平均耗时：
- 是否调用模型：
- 是否写数据库：

【4SAPI】
- 模型耗时：
- 429/504：
- retry_count：
- cost：

【边界】
- 不清空队列
- 不删除死信
- 先给只读分析

3. 常见根因一：Worker 没在跑

最简单也最常见。

队列有任务，但 worker 进程挂了。

检查：

docker compose ps
docker compose logs --tail=200 worker

或者 systemd：

systemctl status worker --no-pager

AI 判断时要看：

worker 是否存在。
是否 crash loop。
是否连接不上 Redis。
是否读取不到环境变量。

4. 常见根因二：重试风暴

某类任务一直失败，又不断重试。

队列看起来很忙。

但都在重复失败。

常见原因：

模型 API 429。
数据库唯一约束冲突。
第三方接口失败。
输入数据格式错。

修复：

限制最大重试。
指数退避。
失败分类。
不可重试错误进死信。

不要无限重试。

5. 常见根因三：模型调用太慢

如果 worker 每个任务都调用 Fable 5，吞吐会很低。

解决方式：

简单任务用低成本模型。
批量任务用并发上限。
长任务拆分。
大任务异步化。
记录每个 task_type 的模型耗时。

4SAPI 日志可以告诉你：

队列慢是不是模型慢。

6. 常见根因四：死信没人看

死信队列不是垃圾桶。

它是事故线索。

AI 可以每天总结死信：

按错误类型分组。
按任务类型分组。
找重复失败。
给修复优先级。

但不要让 AI 直接重放死信。

重放可能再次打爆系统。

7. 短期止血和长期治理

队列积压时，AI 给方案要分两层。

短期止血：

暂停低优先级生产者。
增加 worker，但要看数据库和模型限流。
降低单任务并发。
把不可重试错误送入死信。
临时降级低价值任务。

长期治理：

任务按优先级拆队列。
批量任务和实时任务分 Key。
给每类任务设置最大重试。
记录处理耗时分布。
设置积压告警。

注意：

盲目加 worker 可能把数据库、Redis 或 4SAPI 限流打爆。

所以 Fable 5 做判断时要同时看：

worker 数。
数据库连接数。
模型 API 429。
队列任务类型。

8. 死信报告模板

每天可以让低成本模型生成死信报告：

死信总数：
Top 错误类型：
Top 任务类型：
最早失败时间：
是否同一用户/租户集中：
是否可安全重试：
需要人工处理：

Prompt：

请整理这批死信队列记录。
只做分类和摘要，不重放任务。
标注哪些错误看起来可重试，哪些属于数据错误或权限错误。

死信不是失败的终点。

它是系统改进的入口。

9. 优先级队列设计

如果所有任务都进同一个队列，迟早会出问题。

比如：

用户实时请求。
后台批量摘要。
RAG 重建索引。
每日报表。
失败重试任务。

全混在一起，结果就是：

一个低价值批量任务拖慢高价值实时任务。

建议拆：

realtime：用户等待结果的任务。
normal：普通后台任务。
batch：离线批量任务。
retry：失败重试任务。
dead_letter：需要人工处理任务。

如果任务会调用 4SAPI，还要按模型成本拆：

低成本模型批量队列。
Fable 5 高价值队列。

不要让批量任务随便占用 Fable 5 的额度。

10. Worker 扩容前的检查

很多人看到积压就加 worker。

但加 worker 前要问：

数据库连接数够吗？
Redis 扛得住吗？
4SAPI 是否会 429？
第三方 API 是否限流？
单任务是否本来就太慢？

Fable 5 可以帮你做扩容审查：

请审查这个队列扩容方案。
当前 worker 从 4 增加到 12。
请判断是否会打爆数据库连接池、4SAPI Key 限流或第三方 API。
给出更稳的扩容和限流方案。

很多时候，正确答案不是加 worker。

而是：

限制并发。
拆队列。
降级低价值任务。
修重试策略。

11. 队列告警不要只看长度

队列监控最容易犯的错，是只盯着：

queue_length

但一个队列长度 5000，可能很正常。

比如批量索引任务本来就会在凌晨堆起来，早上慢慢消费。

更好的告警是组合指标：

最老任务等待时间超过阈值。
出队速率连续下降。
失败率突然升高。
重试任务占比超过阈值。
死信连续增长。
4SAPI 429/504 同时升高。

我会把队列告警拆成三类：

告警 含义 处理方向
backlog_age 高 用户等待变长 先看 worker 和单任务耗时
retry_ratio 高 重试风暴 先分类错误，不要加 worker
dlq_growth 高 不可恢复失败变多 先整理死信，不要重放

如果是 AI 任务队列，还要加一类：

model_latency_p95
model_error_rate
model_cost_per_task

这三个指标由 4SAPI 提供最方便。

当队列积压时，让 Fable 5 看到这些指标，它会更容易判断：

是 worker 数量不够。
是模型供应商慢。
是任务设计太重。
还是重试策略把系统拖死了。

一个实用规则：

如果失败率高，不要先扩容。
如果模型 429 高，不要先扩容。
如果数据库连接池满，不要先扩容。

扩容只适合“任务健康，只是消费能力不足”的场景。

这也是为什么队列排查要把业务日志、Worker 日志和 4SAPI 日志放在一张图里看。

12. AI Prompt

你是队列积压排查助手。

请根据队列长度、入队/出队速率、失败率、Worker 状态、任务日志和 4SAPI 模型调用日志，判断积压原因属于：
1. Worker 未运行
2. Worker 数量不足
3. 单任务耗时变长
4. 模型 API 慢或限流
5. 数据库写入慢
6. 重试风暴
7. 死信未处理

要求：
- 不建议清空队列作为第一方案。
- 给只读验证步骤。
- 区分短期止血和长期治理。

13. 总结

队列积压不是一个数字。

要看：

入队。
出队。
失败。
重试。
Worker。
死信。
模型耗时。

4SAPI 能把模型调用耗时和成本接入排查链路。

Fable 5 适合判断复杂积压根因。

一句话：

队列积压不要先清空，先找是谁生产太快、谁消费太慢。