消息积压后如何评估恢复时间？

简化版

积压恢复时间不能用“积压量÷消费速度”直接算，而要用净消化速度：T = backlog / (消费能力 - 新增速率)。若消费能力不高于持续生产速率，积压永远无法清空，必须扩容、降流量或提高单条处理效率。

详细版

先按 Topic、分区和消费组确认积压量、最老消息年龄、生产速率与稳定消费速率，再扣除失败重试和无效消费。计算理论恢复时间后，还要校验分区数上限、下游数据库容量、批量大小、消息大小以及扩容启动和 Rebalance 时间。

恢复应先止住错误重试与下游过载，再分批扩消费者，监控 lag 净下降速度和端到端业务延迟。不能为了清积压跳过幂等、顺序或过期策略；必要时把过期低价值消息按审批规则丢弃或转存，而不是无审计清空队列。

完整版教学

一、先判断积压是否仍在增长

积压是存量，新消息是增量。消费 5000 条/秒看似很高，但生产仍有 6000 条/秒时，每秒还会新增 1000 条，恢复时间不是很长，而是不存在。第一步应在同一时间窗口测生产与成功消费速率。

记忆钩子：清积压看净速度，不看总速度；先让曲线向下，再谈多久归零。

二、基本公式与算例

net_drain_rate = consume_success_rate - produce_rate
recovery_time  = backlog / net_drain_rate

积压 360 万条，生产 2000/s，扩容后成功消费 5000/s，净消化 3000/s，理论需 3600000/3000=1200s，即 20 分钟。若扩容和 Rebalance 花 5 分钟，端到端恢复至少约 25 分钟。

三、为什么要用成功消费速率

拉取 8000/s 不等于处理成功 8000/s。数据库超时后重试、反序列化失败和死信会重复占用资源；应以位点可靠提交或业务成功事实作为完成量。Exactly-once 宣称也不能替代业务指标核对。

指标	说明	易错点
backlog	未完成存量	需按消费组
produce rate	持续新增	峰值会变化
success rate	有效完成	排除失败重试
oldest age	用户实际延迟	比条数更直观

四、分区数决定并行上限

Kafka 同一消费组内，一个分区同一时刻通常只由一个消费者负责。Topic 只有 12 个分区时，扩到 50 个消费者也只有最多 12 个工作。某一热分区积压 80%，整体平均 lag 会掩盖瓶颈，必须看分区级分布。

增加分区会影响 key 顺序、路由与数据分布，不应在事故中无评审操作。可先提升单消费者批处理和并发，但同 key 顺序仍需保持。

五、下游容量才是硬上限

消费者扩容会把压力推给数据库、搜索或第三方接口。下游稳定只能写 4000/s 时，消费端压到 10000/s 会产生超时和重试，实际成功速率反而下降。应先确定下游安全水位，再设置消费限速和批量。

例如数据库正常负载 2500/s、验证余量 1500/s，则恢复额外能力只有约 1500/s，不能把全部理论容量用于追赶。

六、恢复步骤与动态重算

先修复根因、冻结高风险发布、限制失败重试；再按 10%、30%、100% 增加恢复能力，观察下游 P99 与错误率。每 5 分钟用实际净下降量重算 ETA，理论值与实际偏差大时检查热分区、慢消息和限流。

恢复完成的标准不仅是 lag=0，还包括最老消息年龄回落、死信处理完、下游无残留压力，以及业务对账无缺失或重复。

还要核对 Broker 磁盘水位与保留时间：积压增长可能先触发磁盘保护或删除策略，使“尚未消费”的消息在恢复前就不可用。

若消息大小差异很大，应同时按条数和字节估算；一百万条 1KB 消息与一百万条 1MB 消息对网络、磁盘和反序列化的压力完全不同。

七、常见误区与追问

• 误区：恢复时间等于积压量除以消费 QPS。 必须扣除持续生产速率。
• 误区：消费者越多恢复越快。 并行度受分区数和下游容量限制。
• 误区：拉取成功就是消费成功。 应以业务完成和可靠提交位点为准。
• 误区：直接清空积压最快。 会造成业务数据缺失且难以审计。
• 追问：净速度小于等于零怎么办？ 降低生产、扩安全消费能力或隔离流量。
• 追问：为什么看最老消息年龄？ 它直接反映用户经历的端到端延迟。
• 追问：如何估算扩容收益？ 取分区并行、消费者能力和下游余量三者最小值。

八、加强记忆

积压恢复按“存量—增量—净速度—并行上限—下游上限”计算。公式给理论 ETA，分区与下游决定它能否实现；恢复过程分批放量、持续重算，并用位点、最老年龄、死信和业务对账共同确认真正恢复。