标准答案
- 先交代业务场景、峰值流量、影响范围、错误率或延迟，以及缓存失效或积压是如何被发现的。
- 说明根因和放大链路，例如批量过期导致数据库过载，或消费者下游变慢导致重试和积压。
- 说明止血：限流、降级、暂停低价值生产、隔离毒性消息、扩容或恢复依赖，并解释为什么不会扩大数据损失。
- 最后说明恢复：积压清零、缓存重建、索引校对、业务对账和监控改进，明确中间件解决了什么、没有解决什么。
题目解析
事故案例要把组件信号翻译成用户影响和数据风险：缓存批量失效可能让数据库过载，消费者下游变慢可能让消息积压和状态延迟。时间线比组件名更能说明判断质量。
止血要解释为什么不会扩大损失，例如限流、暂停低价值生产、隔离毒性消息、关闭非核心搜索或保留处理中状态。临时扩容只能争取恢复窗口，不能代替根因修复。
恢复验收要包括积压清零、缓存重建、索引校对、重复/丢失对账和监控改进。讲清中间件解决了什么、没有解决什么，才能体现事实来源和失败边界。
常见误区
- 误区：只讲组件故障，不讲业务影响。改正：说明受影响用户、延迟、错误、数据状态和时间线。
- 误区：把临时扩容当作根因修复。改正：补上 TTL、重试、连接、消费或数据模型的长期治理。
- 误区：没有说明重复、丢失和对账结果。改正：明确恢复后如何验证消息、缓存、索引和业务事实已经收敛。