线上消息队列故障，如何做兜底改造？

日期：2026-07-11
标签：#面试 #八股 #后端 #消息队列 #线上问题排查

一句话答案

核心原则是生产不丢、业务可降级、恢复可控：用本地 Outbox/持久缓冲接住关键事件，非核心消息降级丢弃，并在 MQ 恢复后限速回放和对账。

面试口语版

先按消息重要性分级。交易类消息发送失败时，业务事务内写 Outbox 事件，由后台持续重试；已有系统可临时落本地磁盘或数据库，但要有容量和清理上限。通知、埋点等非核心消息可以采样或丢弃，不能拖死主链路。消费侧暂停拉取、保护下游并记录位点。MQ 恢复后先确认集群健康，再按优先级和下游容量限速回放积压，消费者必须幂等，最后通过订单、资金等业务对账补缺。

兜底流程

flowchart LR
  A[业务事务] --> B[Outbox事件]
  B --> C{MQ健康}
  C -->|是| D[发送MQ]
  C -->|否| E[持久等待与告警]
  E --> D
  D --> F[幂等消费]
  F --> G[业务对账]

关键细节

内存队列不是可靠兜底，进程重启会丢。
本地磁盘兜底要防磁盘写满，并考虑容器漂移。
恢复后瞬间回放可能再次压垮 MQ 或下游。
演练生产确认失败、Broker 不可用、积压和重复投递。

面试官追问

Outbox 如何保证业务与消息一致？
本地磁盘兜底有什么风险？
MQ 恢复后如何安全回放？

面试官追问参考答案

1. Outbox 如何保证业务与消息一致？

业务数据和 Outbox 记录写在同一数据库事务中，事务成功就一定存在待发送事件。后台扫描或 CDC 发布到 MQ，确认成功后标记发送；重复发送由消费者幂等处理。

2. 本地磁盘兜底有什么风险？

机器损坏、容器迁移会丢数据，磁盘写满还可能拖垮业务；多实例文件难统一回放。只适合作为短期有界缓冲，应有滚动文件、校验、配额、告警和转储机制，关键事件优先数据库 Outbox。

3. MQ 恢复后如何安全回放？

按业务优先级、时间和分区顺序分批回放，使用令牌桶限制速率，并观察 Broker、消费者和下游水位。消费者保证幂等，失败进入重试/死信；对账确认完成后再清理兜底数据。

学习清单

掌握 Outbox 和幂等消费。
能说明故障期降级与恢复期限速。