队列积压估算是什么
队列积压量本身不是问题，积压多久能清掉才是。清理时间等于积压量除以净消化速率，而净消化速率是消费速率减去生产速率——只要两者接近，积压就会长时间停留在高位，甚至永远清不完。所以容量设计要保证消费能力对生产峰值留有余量，告警口径也更适合用「预计处理时长」或字节数而不是单纯的消息条数，因为条数在不同消息大小下含义完全不同。
基本信息
| 核心公式 | 清理时间 = 积压量 / （消费速率 - 生产速率） |
|---|---|
| 告警口径 | 优先用预计处理时长或积压字节数，条数仅作参考 |
| 健康指标 | 最老消息年龄、消费延迟、消费失败率与重试量 |
| 容量要求 | 消费能力按生产峰值配置余量，通常保留 1.5 倍以上 |
| 处置手段 | 扩容消费者、提高批量、暂停非关键生产者、临时降级 |
典型使用场景
- 大促前后评估：判断积压是否能在业务可接受的时间内清空
- 故障恢复：下游恢复后估算追平延迟需要多久
- 告警阈值设定：把「预计 x 分钟清不完」作为告警条件
- 扩容决策：判断加消费者有效还是瓶颈在数据库写入
- 生产限流：上游生产过快时先在入口限流，而不是无限堆队列
- 批任务与在线共用队列：识别批量任务挤占在线处理能力的风险
估算示例
估算示例
# 净消化速率 = 消费速率 - 生产速率
# 清理时间 = 积压量 / 净消化速率
积压 100 万条，消费 2000/s，生产 1500/s
→ 净消化 500/s → 清理需 1000000 / 500 = 2000s ≈ 33 分钟
# 反向核算：若要求 10 分钟内清完 100 万条
# 需要净消化 1667/s，生产 1500/s 时消费需达到约 3167/s
# 结论：单靠优化消费端不够，需同时在上游限流或削峰积压时的判断顺序
| 现象 | 先看什么 | 常见结论 |
|---|---|---|
| 积压持续增长 | 生产速率与消费速率 | 消费能力不足，或上游突发流量 |
| 积压高位不降 | 消费是否被下游限速 | 瓶颈在数据库或外部接口，扩容消费者无效 |
| 最老消息年龄上升 | 单个分区是否有慢消息 | 分区热点或个别大消息阻塞 |
| 反复清理又反复积压 | 上游是否有定时任务 | 批量任务与在线消费互相挤占 |
| 重试量同步上升 | 消费失败原因 | 下游故障导致消费失败，需先止血 |
不要只用条数告警：同样一百万条，平均 1KB 与平均 1MB 的处理时长差两个数量级，用预计处理时长或字节数作口径更稳。
扩容消费者前先确认瓶颈：如果瓶颈在数据库写入或下游接口限流，加消费者只会加重失败与重试，先限流再扩容更有效。