场景题思考

这篇笔记的目标不是把零散场景题逐个背答案，而是把高频问题拆成「结论 -> 原理 -> 方案对比 -> 落地细节 -> 风险边界」的回答方式

参考资料：

官方文档：RabbitMQ Publisher Confirms 、 Kafka Producer Configs 、 Kafka Consumer Configs 、 RocketMQ Retry Policy

工程实践：Transactional Outbox

[TOC]

1. 如何保证 MQ 消息不丢失

这个问题表面上在问消息队列，实际考察的是系统可靠性设计。更完整的分析通常不会停留在“持久化”和“重试”两个词，而是会继续展开 DB-MQ 一致性、ACK 时机、幂等、死信队列、监控告警与对账补偿。

1.1 先给最短答案

如果只用一句话概括这个问题：

MQ 消息不丢失，不是只靠消息队列本身，而是要把 生产端发送成功、Broker 持久化成功、消费端处理成功、失败后可重试可补偿 这四层同时补齐。

再进一步压缩成面试里的回答框架，可以概括成 4 句话：

1. 生产端不能“发了就当成功”，要有 发送确认，必要时配合 本地消息表 / Outbox 或事务消息。
2. Broker 不能只放内存，队列和消息要 可持久化，并通过 副本、刷盘、高可用 提高存活概率。
3. 消费端不能先确认后执行业务，要做到 处理成功再 ACK / 提交 offset，失败则重试或进入死信队列。
4. 业务上不能迷信“绝对不丢”，要补 幂等、对账、告警 和 补偿，把“偶发失败”变成“最终可恢复”。

如果只回答“开启持久化”通常是不够的，因为真正容易丢消息的地方，往往不是某一个配置项，而是整条链路里存在确认缺口。

1.2 消息到底会在哪些地方丢

先把消息链路拆开，这个问题就容易回答很多。

graph TB
    A[业务线程写库] --> B[生产者发送消息]
    B --> C[Broker 接收消息]
    C --> D[Broker 落盘与副本同步]
    D --> E[消费者拉取消息]
    E --> F[消费者执行业务]
    F --> G[ACK 或提交 offset]
    B -.发送失败重试.-> B
    D -.持久化失败告警.-> H[补偿与人工介入]
    F -.业务失败重试.-> I[重试队列]
    I --> E
    I -.超过阈值.-> J[死信队列]

消息丢失通常发生在下面几段：

所以“保证不丢失”的正确理解不是“系统里再也不会有异常”，而是：

• 关键节点都要有确认机制。
• 短暂失败后要能自动重试。
• 不确定状态要能靠幂等和补偿收敛。
• 最后还要有监控和对账把漏网之鱼兜住。

1.3 面试里应该先给出哪种判断

这个问题先不要急着谈具体中间件，先给出一个边界判断会更稳：

分布式系统里很难承诺数学意义上的“100% 永不丢失”，更现实的目标是把消息变成“高概率不丢 + 丢了可发现 + 发现后可恢复”。

这句话的价值在于，它把回答从“背配置”拉回到“可靠性工程”。

可以把不同层面的目标拆成下面这张表：

很多回答之所以显得空，是因为只覆盖了前两行，却漏掉了消费端和业务端。

1.4 生产端如何保证消息不丢

生产端是最容易被忽略、但实际上最容易丢消息的一段。

1.4.1 不要用“写完库再随手发消息”的方式

最危险的写法通常是下面这种顺序：

1. 业务事务提交成功。
2. 代码继续调用 send(message)。
3. 发送之前应用宕机，或者发送超时且没有补偿。

这样数据库状态已经变了，但消息根本没有出去，后续异步链路就彻底断掉了。

因此生产端最重要的不是“会不会调用发送 API”，而是要解决 业务数据 和 消息发送 之间的一致性问题。

1.4.2 常见的生产端方案

如果场景是订单创建、支付完成、库存扣减这类关键链路，优先级通常是：

本地事务写业务表 + 写消息表 -> 后台投递消息 -> 发送成功后更新消息状态

这个模式本质上就是 Outbox。它的核心价值在于：

• 业务数据和待发送消息一起提交，要么都成功，要么都失败。
• 即使应用在提交后立刻宕机，消息记录仍在数据库里。
• 后台任务可以继续扫描未发送记录并补发。

1.4.3 发送到 Broker 时要拿到确认

即使使用了 Outbox，真正发送时也不能 fire-and-forget，仍然要有确认机制。

不同中间件的思路虽然配置不同，但原则一致：

面试里如果能补一句“生产端的成功，不是代码执行到 send() 就算成功，而是拿到 Broker 的可靠确认才算”，通常会比单纯说“重试一下”更完整。

1.4.4 生产端还需要哪些补充手段

• 消息唯一 ID：方便幂等、排查、对账和补发。
• 发送重试：针对网络闪断、超时这种瞬时故障做有限次重试。
• 失败落库：超过重试阈值后进入待补偿状态，而不是直接吞掉异常。
• 发送监控：关注发送失败率、重试次数、未发送消息表积压。

1.5 Broker 端如何保证消息不丢

Broker 侧的核心问题是：消息到了队列，是不是已经“可靠地活下来”。

1.5.1 持久化不是一个可有可无的选项

如果队列、Topic 或消息本身没有做持久化，那么 Broker 重启或宕机之后，消息天然就可能消失。

因此 Broker 侧至少要做到：

• 队列或 Topic 是持久化配置。
• 消息本身按可靠消息方式写入。
• 不依赖单节点内存保存关键消息。

1.5.2 只做持久化还不够，还要考虑副本与确认语义

很多系统并不是“消息没落盘”，而是“消息刚到主节点，主节点还没同步副本就挂了”。

因此更完整的思路是：

如果是 Kafka，通常会强调：

• acks=all
• replication factor >= 3
• min.insync.replicas >= 2
• 不接受“只写 leader 就立刻返回成功”的弱确认配置

如果是 RabbitMQ 或 RocketMQ，也同样要强调持久化与副本，而不是只说“开启消息持久化”就结束。

1.5.3 Broker 端的监控也很关键

Broker 侧的“消息不丢”不只是配置问题，还要盯住运行状态：

• 磁盘使用率是否逼近上限。
• 副本是否频繁掉队。
• Topic / Queue 是否长时间积压。
• Broker 切换、重启、刷盘异常是否有告警。

否则配置再正确，运行时失控照样可能把可靠性打穿。

1.6 消费端如何保证消息不丢

消费端的核心原则通常只有一句：

先执行业务，成功之后再确认消息；失败则不要确认，让系统有机会重试。

1.6.1 ACK 或 offset 提交时机必须放对

消费端最常见的错误，是消息一拉到就自动确认，然后再去执行业务逻辑。这样如果业务执行过程中宕机，消息已经被 Broker 认为“处理完成”，自然就丢了。

更稳的顺序应该是：

1. 拉取消息。
2. 执行业务逻辑。
3. 本地事务提交成功。
4. 再 ACK 或提交 offset。

这一点在不同中间件里的表现形式不同，但原则不变：

1.6.2 消费端一定要有幂等

一旦强调“失败后重试”，就必须接受另一个现实：消息可能重复到达。

所以真正完整的设计不是“既不丢也不重”，而是：

消息允许重复投递，但业务处理结果必须保持幂等。

常见幂等手段包括：

• 基于 业务唯一键 去重，例如订单号、支付流水号、业务事件 ID。
• 基于数据库 唯一索引 防止重复插入。
• 基于状态机控制，只允许状态按合法方向推进。
• 为消费记录单独建表，记录消息 ID 和处理状态。

1.6.3 重试和死信队列要配套

不是所有失败都值得无限重试。

可以把消费失败分成两类：

如果没有死信队列，永久失败消息可能会在系统里反复打转，最后把消费能力拖垮。

1.7 真正难点在于数据库和 MQ 的一致性

“如何保证 MQ 消息不丢失”这个问题，最应该展开的地方往往就是 DB 和 MQ 的一致性。

因为最致命的不是 Broker 丢了某条消息，而是：

• 订单已经创建成功，但“订单已创建”事件没发出去。
• 支付已经完成，但“支付成功”消息没发出去。
• 库存已经扣减，但后续履约链路完全不知道。

这类问题会直接造成业务状态断裂。

1.7.1 为什么不能指望普通本地事务一次搞定

数据库事务只能保证数据库自己的提交与回滚，不能天然覆盖外部消息系统。也就是说：

• DB commit 成功，不代表 MQ send 一定成功。
• MQ send 成功，也不代表后续业务逻辑一定成功。

所以这不是“多写几行 try-catch”能解决的，而是需要专门的一致性模式。

1.7.2 三种思路的取舍

在大多数互联网系统里，Outbox + 重试 + 幂等 + 对账 是性价比最高的答案。

1.7.3 一个可执行的 Outbox 流程

sequenceDiagram
    participant App as 业务服务
    participant DB as 业务库
    participant Relay as 投递程序
    participant MQ as Broker
    participant Consumer as 消费者

    App->>DB: 本地事务写业务表
    App->>DB: 本地事务写 outbox 消息表
    DB-->>App: 提交成功
    Relay->>DB: 扫描未发送消息
    Relay->>MQ: 发送消息
    MQ-->>Relay: 发送确认
    Relay->>DB: 更新消息状态为已发送
    Consumer->>MQ: 拉取消息
    Consumer->>Consumer: 执行业务并幂等校验
    Consumer-->>MQ: 成功后 ACK

这套模式即使在几个关键节点发生故障，也仍然有恢复抓手：

• 应用提交后宕机：outbox 记录还在，投递程序后续继续补发。
• Broker 短暂不可用：投递失败，消息仍留在消息表里等待下一次发送。
• 消费端失败：消息不确认或进入重试队列。
• 重试导致重复投递：由消费端幂等兜住。

1.8 一个下单场景的完整落地方案

假设现在有一条业务链路：

用户下单成功后，需要异步通知库存系统扣减库存，再通知积分系统发放积分。

如果只追求“功能跑通”，最容易写成：

1. 订单服务写订单表。
2. 订单服务直接发 order_created 消息。
3. 库存服务、积分服务各自消费。

这套写法的问题是：订单入库成功后，消息发送动作可能失败，导致库存和积分根本感知不到。

更稳的落地方案可以这样设计：

如果要把这段方案压缩成一句工程结论，可以概括为：

关键不是“消息一定只投一次”，而是“消息即使因为故障出现迟到、重试或重复，整个业务链路仍然能最终收敛到正确状态”。

1.9 常见误区

1.9.1 以为开启消息持久化就万事大吉

持久化只解决了 Broker 某一层的问题，生产端未发送成功、消费端过早确认、业务端重复处理，这些都不是“持久化”能覆盖的。

1.9.2 以为消息不丢失就等于绝不重复

为了抗故障，系统经常必须允许重试和重复投递。因此实际工程里追求的是 at-least-once + 幂等，而不是口头上的“既不丢也不重”。

1.9.3 以为 Broker 能替业务兜住所有一致性问题

真正的业务一致性，最终还是要回到业务系统自己的状态管理、补偿机制和对账闭环。中间件只能提供可靠传递，不能替业务做最终语义判断。

1.9.4 以为失败重试就已经形成闭环

没有死信队列、没有告警、没有人工介入入口的重试体系，通常不算完整闭环。因为永久失败消息最终还是需要被发现、被定位、被处理。

1.10 一段可直接复述的回答模板

如果需要压缩成一段较短回答，可以按下面这个顺序展开：

MQ 消息不丢失要分三段看。第一段是生产端，不能只在业务成功后直接发消息，而是要有发送确认；关键链路通常会用本地消息表或者事务消息，保证业务数据和待发送消息的一致性。第二段是 Broker 端，队列和消息都要持久化，并通过副本和合理的确认语义提升可靠性。第三段是消费端，必须处理成功后再 ACK 或提交 offset，失败走重试或死信。除此之外，还要靠幂等、对账和告警做最后兜底，因为分布式系统里更现实的目标是高可靠、不丢主流程、出了问题可恢复。

这个版本的重点不是背术语，而是顺序清晰，且能覆盖生产、存储、消费和业务闭环四个层面。

1.11 小结

“如何保证 MQ 消息不丢失”这个问题，真正考察的不是是否知道几个配置项，而是能不能把可靠性问题拆成一条完整链路：

• 生产端要解决发送确认和 DB-MQ 一致性。
• Broker 端要解决持久化、副本和高可用。
• 消费端要解决 ACK 时机、重试和死信。
• 业务端要解决幂等、对账和补偿。

只要分析里同时覆盖这四层，内容就不会显得空。顺着这条链路继续往下看，后面几个高频问题通常就是：消息重复、消息乱序、消息积压，以及更上层的分布式事务落地。

2. 如何保证消息不重复消费

2.1 先给最短答案

这个问题的最短答案通常是：

很多 MQ 系统天然更容易提供的是 at-least-once，也就是“宁可重复，不轻易丢失”。所以真正的落地目标通常不是“物理上永不重复”，而是“允许消息重复投递，但业务结果保持幂等”。

如果把回答压缩成面试里的 4 句话，可以概括成：

1. 先承认重复消费是可靠消息体系里的常见现象，不能假设每条消息只到一次。
2. 消费端要基于 业务唯一键 / 消息唯一 ID / 状态机 做幂等控制。
3. ACK 或 offset 只能在业务成功后提交，否则既可能丢，也可能反复重试。
4. 对于关键链路，要补消费记录、重试、死信和对账，把重复影响收敛到可控范围内。

2.2 为什么消息会重复消费

消息重复通常不是系统“坏掉了”，而是可靠性设计下的自然结果。

最常见的重复场景包括：

也就是说，重复和丢失其实是一对跷跷板。系统越倾向于“不要丢”，就越要接受“可能重”。

2.3 不要把“恰好一次”理解成不用做幂等

很多分析会在这里直接说 exactly-once，但这类表述很容易说过头。

更稳妥的说法是：

中间件层面的 exactly-once 往往有严格前提，通常只能覆盖“消息系统内部的生产与消费语义”，不能自动覆盖业务数据库、缓存、第三方接口这些外部副作用。

所以即使某些组件宣称支持更强语义，业务层仍然需要幂等。

可以把不同层次拆成下面这张表：

只要业务里发生“写库、扣库存、发券、调第三方”这类副作用，就不能把“去重”完全寄托给 MQ。

2.4 消费端一般怎么做幂等

消费端最常见的幂等方案有下面几类：

一句话概括，最稳的组合通常是：

业务唯一键 + 数据库约束 + 状态机 作为主兜底，Redis 作为性能优化，而不是把正确性完全压在缓存上。

2.5 一个常见的消费幂等流程

flowchart TD
    A[收到消息] --> B[提取 messageId / businessKey]
    B --> C{是否已处理}
    C -- 是 --> D[直接返回成功]
    C -- 否 --> E[执行业务逻辑]
    E --> F{业务成功}
    F -- 否 --> G[不提交 ACK 进入重试]
    F -- 是 --> H[记录处理状态]
    H --> I[提交 ACK / offset]

这张图里最关键的点有两个：

• “是否已处理”的判断必须基于稳定键，而不是临时内存状态。
• “记录处理状态”和“业务成功”之间尽量放在同一个本地事务里，否则去重记录和业务结果可能再次分叉。

2.6 一个支付回调型案例

假设支付系统会投递 pay_success 消息，下游订单系统要把订单状态改成“已支付”。

如果没有幂等，可能发生的问题是：

1. 第一次消费成功，把订单从“待支付”改成“已支付”。
2. ACK 因网络闪断失败，Broker 再次投递。
3. 第二次消费又重复发积分、重复写流水、重复触发履约。

更稳的做法通常是：

这种设计下，即使消息重复到来，第二次处理也只会发现：

• 支付流水已存在
• 订单状态已是 已支付
• 本次重复消息不再触发额外副作用

2.7 常见误区

2.7.1 以为去重就是查 Redis

Redis 很适合做高性能拦截，但如果只靠 SETNX 做最终正确性兜底，一旦缓存丢失、过期或主从切换，仍然可能重复执行业务。

2.7.2 以为 ACK 提前一点没关系

过早提交 ACK 或 offset 会把“还没执行业务成功”的消息直接从 Broker 视角标记为完成，最终造成丢消息或语义紊乱。

2.7.3 以为 MQ 保证一次投递就够了

业务副作用往往发生在数据库和第三方接口里。即使消息系统层面很强，业务层没有状态机和唯一约束，重复问题照样存在。

2.8 一段可直接复述的回答模板

MQ 消息不重复消费，本质上不是要求 Broker 永远只投一次，而是要求业务结果只生效一次。因为为了保证可靠性，很多消息系统默认是 at-least-once，所以消费端要按幂等来设计。常见做法是基于业务唯一键或消息 ID 做去重，对关键表建立唯一索引，用状态机控制状态只能推进一次，并且在业务成功之后再提交 ACK 或 offset。对于关键链路，还要补消费记录、重试、死信和对账，这样即使消息重复到达，也不会把业务做坏。

2.9 小结

这个问题的关键不是“怎么让消息物理上绝不重复”，而是：

• 接受可靠消息体系下“可能重复”的现实。
• 把幂等落到业务唯一键、数据库约束和状态机上。
• 把 ACK 时机放到业务成功之后。
• 把补偿、死信和对账做成闭环。

3. 如何保证消息顺序消费

3.1 先给最短答案

这个问题很容易答散，所以先收成一句话：

消息顺序消费的核心，不是让整个 MQ 集群只有一个消费者，而是让“同一业务键”的消息始终进入同一个有序通道，并由同一时刻的单线程或串行语义来处理。

如果压缩成面试里的回答框架：

1. 先区分“全局顺序”和“局部顺序”，实际工程里大多数只追求局部顺序。
2. 生产端要按 orderId / userId / aggregateId 这类业务键进行一致性路由。
3. Broker 端要保证同一键落到同一 queue / partition。
4. 消费端要对同一有序通道串行消费，并处理失败重试、阻塞和乱序补偿问题。

3.2 先分清全局顺序和局部顺序

很多回答一上来就说“单队列单消费者”，这在概念上没错，但工程上太贵。

可以先把顺序分成两种：

所以大多数业务真正要的是：

同一个订单的 创建 -> 支付 -> 发货 -> 完成 不能乱，但不同订单之间完全可以并行。

3.3 消息为什么会乱序

消息乱序通常发生在下面几个位置：

所以“顺序消费”绝不是只在 Broker 上配个参数就结束，而是生产、存储、消费三段同时约束。

3.4 一个稳定的顺序消费思路

flowchart LR
    A[业务事件 orderId=1001] --> B[按 orderId 取模路由]
    B --> C[固定落到 Queue-3]
    C --> D[消费者实例 A]
    D --> E[单线程串行处理]
    A2[业务事件 orderId=1002] --> B2[按 orderId 取模路由]
    B2 --> C2[固定落到 Queue-7]
    C2 --> D2[消费者实例 B]
    D2 --> E2[单线程串行处理]

这张图背后的原则其实很简单：

• 同一业务键固定路由到同一分区。
• 同一分区同一时刻只允许一个消费线程按顺序处理。
• 不同分区之间并行，从而保住整体吞吐。

3.5 一般怎么落地

如果是订单、支付这类流程型业务，最稳的答案通常是：

顺序性靠 分区键 + 串行消费 + 状态机校验 三层一起兜底。

3.6 顺序和吞吐一定是互相拉扯的

这里更有价值的地方，不是把“顺序”说成一个纯配置题，而是把代价和边界讲清楚。

所以很多场景不会盲目追求“全局强顺序”，而是根据业务键做局部顺序。

3.7 一个订单状态流转案例

假设订单相关消息有 4 类：

1. order_created
2. order_paid
3. order_shipped
4. order_finished

如果这些消息按 orderId 做分区键，就能保证同一个订单始终进同一分区。

但仅仅如此还不够，业务层还要防两类问题：

• order_paid 重试慢，order_shipped 先到了。
• 补偿链路重新投递一条旧的 order_created。

所以订单表状态推进通常要做成：

只允许合法状态前进，即使出现极端乱序，也不会把订单从 已发货 又打回 待支付。

3.8 rebalance / 重启时的边界风险

顺序消费在稳定运行时往往不难理解，真正容易出问题的地方通常出现在消费者扩缩容、实例重启、故障转移这些“交接边界”上。

这一段最重要的两个概念可以先翻成更直观的中文：

可以把这件事理解成“接力棒交接”：

• ownership 是接力棒当前在谁手里。
• in-flight message 是已经起跑、但还没跑到终点交卷的那几棒。

如果交接发生在这些消息尚未彻底处理完成的时候，边界风险就出现了。

3.8.1 为什么新增消费者会引发边界问题

新增消费者之后，中间件通常会重新分配有序通道给各实例。这个重新分配过程，在很多消息系统里就叫 rebalance。

它本身不是错误，而是为了把消费负载重新摊开。

风险来自下面这个事实：

有序通道的归属会变化，但旧实例手里可能还有一批已经拉下来、尚未最终确认完成的消息。

这时如果交接处理得不干净，就容易出现 3 类问题：

3.8.2 为什么重启和 rebalance 的问题本质上是一类

消费者重启时，虽然表面上只是“进程重启一下”，但从顺序消费的视角看，本质上仍然是：

1. 旧实例失去这条有序通道的处理权。
2. 新实例或重启后的实例重新拿到处理权。
3. 中间件需要决定从哪里继续消费。

所以无论是扩容触发 rebalance，还是实例崩溃后重新拉起，真正的风险都集中在两件事：

• 旧实例有没有把手里的在途消息处理完。
• 新实例是不是从正确的位置继续接手。

3.8.3 一张图看交接边界

sequenceDiagram
    participant Broker as 有序通道
    participant A as 消费者A
    participant B as 消费者B
    participant DB as 业务库

    Broker->>A: 投递 M1、M2
    A->>DB: 开始处理 M1
    Note over A: M1 已拉取但尚未确认\n这就是 in-flight message
    Note over Broker: 发生 rebalance 或 A 重启
    Broker->>B: 通道归属切换给 B
    Note over Broker,B: ownership 已变化
    B->>Broker: 从上次已提交位置继续拉取
    B->>DB: 开始处理 M1 或 M2
    A-->>Broker: 旧确认晚到或确认失败

这张图里真正要防的不是“中间件突然乱序”，而是：

• A 处理中的消息还没收尾。
• 通道归属已经切给 B。
• B 又从旧位置重新开始或继续推进。

如果业务层没有幂等和状态机，这时很容易在外部表现成“顺序错了”。

3.8.4 什么时候顺序不会出问题

交接边界要尽量满足下面这个顺序：

1. 旧实例停止继续拉新消息。
2. 旧实例把当前在途消息处理完。
3. 旧实例提交已经成功处理的消费位置。
4. 再释放这条有序通道的处理权。
5. 新实例从最新已确认位置开始继续处理。

可以概括为：

先收尾，再交接；先确认，再放权。

只要这个交接链路做得足够干净，新增消费者本身并不会天然破坏顺序。

3.8.5 什么时候最容易出问题

下面几种做法最容易把边界风险放大：

所以顺序消费里的“边界安全”，本质上不是单靠中间件保证，而是消费模型和业务模型一起约束。

3.8.6 一个更贴近实战的案例

假设有一条订单状态链：

1. order_created
2. order_paid
3. order_shipped

并且同一个 orderId 的消息始终进入同一个有序通道。

某次扩容前：

• 消费者 A 同时负责两条有序通道。
• orderId=1001 所在的那条通道归 A 处理。

某次扩容后：

• 新增消费者 B
• 通道重新分配
• orderId=1001 所在的那条通道切给 B

如果此时发生下面这个边界过程：

业务上的风险就来了：

• order_paid 可能被重复执行。
• 如果 order_shipped 在另一条异步链路里先落库，看起来就像“发货早于支付”。
• 如果订单状态更新没有做条件约束，旧状态和新状态可能互相覆盖。

更稳的做法通常是：

3.8.7 这一节真正要记住什么

顺序消费在 rebalance / 重启 边界上的关键，不是“消费者数量变化了”，而是：

• 某条有序通道的处理权是否在切换。
• 旧实例手里的在途消息是否已经收尾。
• 新实例接手的位置是否正确。
• 业务层是否能承受短暂重复而不发生状态错乱。

一句话概括：

顺序消费最怕的不是扩容本身，而是有序通道在交接时，旧实例还没收尾，新实例已经开始继续处理。

3.9 常见误区

3.9.1 以为顺序消费就是单机单线程

真正可用的做法不是整个系统单线程，而是“同一业务键串行，不同键并行”。

3.9.2 以为 Broker 有序就等于业务有序

即使 Broker 保住了投递顺序，消费端多线程、重试绕行、业务状态机缺失，依然会让结果乱掉。

3.9.3 以为顺序和失败重试互不影响

顺序链路里前一条消息失败，往往会阻塞后续消息，所以必须提前设计重试上限、死信和人工补偿。

3.10 一段可直接复述的回答模板

消息顺序消费要先区分全局顺序和局部顺序，实际项目里大多追求的是局部顺序，也就是同一个订单或同一个用户的消息有序。常见做法是生产端按业务键做一致性路由，让同一键固定落到同一个 queue 或 partition，消费端对同一分区串行处理，不在分区内并发。除此之外，业务层还要有状态机校验，防止失败重试或补偿消息把顺序打乱。也就是说，顺序消费不是单靠 MQ 配置，而是分区路由、串行消费和业务状态约束一起完成。

3.11 小结

顺序消费真正要记住的是：

• 先区分全局顺序和局部顺序。
• 用业务键把同一类消息固定到同一通道。
• 分区内串行，分区间并行。
• 在 rebalance / 重启 边界上先收尾再交接。
• 用状态机兜住极端乱序和补偿重放。

4. 消息积压了怎么办

4.1 先给最短答案

这个问题的最短答案可以概括为：

消息积压本质上是“生产速度持续大于消费速度”。处理时不要只盯着 MQ 本身，而要先判断积压规模和增长趋势，再分成“止血、扩容、削峰、定位根因、补监控”这几个动作。

如果压缩成回答框架，通常是：

1. 先看积压量、增长速度、影响 Topic 和业务优先级。
2. 再判断是短时流量尖峰，还是消费端故障、慢 SQL、外部依赖变慢造成的持续积压。
3. 临时止血可以通过扩消费者、限流生产端、降级非核心消费、跳过低优先级任务来做。
4. 最终要回到根因治理，包括消费逻辑优化、热点隔离、重试治理和监控告警。

4.2 先判断这是不是“真正的问题”

不是所有积压都代表事故。

更稳妥的判断维度通常有 3 个：

有些场景天生就是削峰填谷，短时间积压是设计的一部分；真正危险的是：

• 积压在持续增长
• 最老消息延迟已经穿透业务 SLA
• 重试消息把正常队列也拖慢了

4.3 常见根因通常不在 MQ 本身

消息积压最常见的根因通常是下游变慢。

所以面试里如果只回答“扩容消费者”，通常不够完整。因为有些积压扩容也救不了，比如慢 SQL 或死循环重试。

4.4 先止血，再排根因

积压真的已经影响业务时，处理顺序通常可以概括成下面这张图：

flowchart TD
    A[发现积压告警] --> B[判断是否持续增长]
    B --> C{是否影响核心业务}
    C -- 是 --> D[核心链路优先保流量]
    D --> E[扩消费者 / 限流生产 / 暂停低优先级]
    C -- 否 --> F[观察并定位根因]
    E --> G[排查消费端瓶颈]
    F --> G
    G --> H[修复慢 SQL / 超时 / 重试风暴]
    H --> I[回补消费能力]
    I --> J[补监控与容量评估]

这套顺序的关键是：

• 事故处理中先保核心链路。
• 不要在根因未明时盲目重启一切。
• 扩容只是争取时间，真正要解决的是消费速度为什么掉下来了。

4.5 常见的临时止血手段

一个常见误区是：看到积压就立刻把消费线程数翻倍。这样如果瓶颈在数据库，往往只会把下游一起打穿。

4.5.1 如果已经是存量积压了，新增消费者到底还有没有用

这里有一个很关键的边界：很多分析会把“存量积压”误解成“已经写进 Broker 了，所以再扩消费者也没意义”。这种理解并不准确。

更准确的表述是：

积压虽然是存量数据，但它仍然要靠消费者从 Broker 持续拉取并处理掉。所以只要当前瓶颈真的是“消费并行度不够”，并且 backlog 分散在多个 queue / partition 上，新增消费者依然可以加快存量回补。

什么时候新增消费者有用，通常看下面这张表：

也就是说，新增消费者不是因为“消息是新增还是存量”来判断有没有用，而是看：

1. 还有没有剩余并行槽位。
2. 真正瓶颈是不是消费者实例数。
3. backlog 是均匀分布还是集中在热点分区。

4.5.2 为什么有时候扩消费者之后，积压还是几乎不动

常见原因通常有 4 类：

因此更准确的结论不是“扩容没用”，而是：

扩容只有在“有可分配并行度 + 下游扛得住”的前提下才有意义。

4.5.3 如果消费者数量已经远远大于 broker 数量，新增消费者还有用吗

这里最容易混淆的是：有效并行上限通常不是 broker 机器数，而是消费组可并发消费的 queue / partition 数。

可以概括成：

• broker 决定的是存储和服务节点规模。
• queue / partition 决定的是同一个消费组能切出来多少并行消费通道。
• consumer instance 决定的是这些通道最终分给多少实例处理。

所以常见判断规则是：

这也是为什么在 Kafka、RocketMQ 这类中间件里，经常会说：

想提升同组消费能力，先看 partition / queue 够不够，不够的话单纯加消费者实例没有意义。

4.5.4 如果 backlog 已经形成了，怎么快速处理存量数据

面对大量存量 backlog，常见动作通常不是“只加消费者”这一招，而是下面几类组合：

更稳妥的处理顺序通常是：

• 第一步：先止住新增流量的继续恶化。
• 第二步：把正常消息和异常重试消息拆开。
• 第三步：再决定是在线扩容回补，还是离线批量回放。

4.5.5 遇到“单分区存量 backlog”时，为什么扩消费者基本无解

如果积压集中在一个热点 queue / partition，那说明吞吐瓶颈已经被锁在这条单通道上了。

这时候新增同组消费者通常没有效果，因为：

• 同一分区同一时刻只能分配给一个消费者实例。
• 想并行拆分这批旧消息，就要改变原有分区策略。
• 一旦强行拆分，往往会引入顺序风险和重复处理风险。

因此这类场景更现实的解决思路通常是：

1. 判断这条热点消息是否真的要求严格顺序。
2. 如果不要求严格顺序，考虑转储历史 backlog 到新 Topic，多分片并行回放。
3. 如果要求严格顺序，只能优化单条处理耗时、减少重试阻塞，或接受该分区线性回补。

一句话概括：

单分区热点 backlog 的本质不是“消费者不够多”，而是“并行切分能力不够”。

4.6 根因修复一般看什么

积压背后最值得查的通常是下面这些指标：

• 单条消息平均处理耗时、P95、P99。
• 消费失败率和重试率是否突然升高。
• 下游数据库慢 SQL、连接池等待、锁等待。
• RPC 超时率、线程池拒绝数、熔断次数。
• 热点 key 或热点分区是否明显倾斜。
• 是否刚发过版，或刚切换过流量。

如果要把这部分压缩成更工程化的表达，可以概括为：

先确认“积压是结果”，再定位“谁把消费速度拉低了”。

4.7 一个订单履约链路的案例

假设 order_created Topic 突然积压了 200 万条消息，最老消息延迟已经 40 分钟。

排查顺序通常可以是：

1. 看积压是否还在持续增长。
2. 看是不是只有某个消费组积压，而不是所有消费组。
3. 看最近是否有发布、配置变更、数据库慢 SQL 或外部接口超时。
4. 看失败重试队列是否把正常消费线程占满。

如果定位到原因是“库存服务调用慢 + 重试风暴”，比较稳的处理动作是：

4.8 常见误区

4.8.1 以为积压就是 MQ 宕了

大多数积压事故都不是 Broker 本身挂掉，而是消费端慢、失败重试风暴或下游依赖性能下降。

4.8.2 以为扩容一定有效

如果瓶颈在慢 SQL、外部接口或锁竞争，盲目扩容只会把下游放大成更大的事故。

4.8.3 以为把积压清空就算结束

真正的收尾动作还包括回补、复盘、容量评估和监控补齐，否则下一次峰值还会复发。

4.9 一段可直接复述的回答模板

消息积压本质上是生产速度持续大于消费速度。处理时应先看积压量、增长趋势和最老消息延迟，判断是否已经影响核心业务；再区分根因到底是流量尖峰、消费端变慢、下游依赖故障还是重试风暴。对于已经形成的存量 backlog，不能简单概括为“多加消费者”，而是要先看消费组还有没有剩余 queue / partition 并行度，因为真正的上限通常不是 broker 数，而是可分配的分区数；如果消费者数已经超过分区数，再扩容基本没有收益。临时止血可以通过扩容消费者、限流生产端、暂停低优先级消费、拆分重试流量、必要时把历史 backlog 转储到新 Topic 多分片回放来做。最终还是要回到消费端耗时、慢 SQL、RPC 超时、热点分区和重试策略这些根因上，并补上积压和延迟监控。

4.10 小结

处理积压要记住 4 个词：

• 先判断：规模、趋势、延迟。
• 先止血：保核心、控重试、先看并行度上限再扩容。
• 查根因：慢消费、慢依赖、热点、风暴。
• 做闭环：回补、复盘、监控、容量治理。

5. 分布式事务怎么落地

5.1 先给最短答案

这个问题很容易被写成“背 XA / TCC / Saga 名词”，但更稳妥的展开应该先给结论：

分布式事务落地的关键，不是追求一种放之四海而皆准的方案，而是先看业务到底要“强一致”还是“最终一致”，再在 本地消息表 / 事务消息 / TCC / Saga / XA 之间做取舍。

如果压缩成面试里的回答框架：

1. 大多数互联网业务优先接受最终一致，而不是直接上两阶段提交。
2. 跨服务写库后要触发后续动作时，优先考虑 Outbox / 事务消息。
3. 需要明确预留资源和补偿语义时，再考虑 TCC 或 Saga。
4. 真正的极少数强一致场景，才会评估 XA / 2PC，并接受性能和可用性代价。

5.2 先分清“事务问题”到底是哪一类

很多人一听到分布式事务，就直接上框架名。更稳的方法是先分类。

先把业务类型说清楚，后面的方案才不会显得像背八股。

5.3 常见方案怎么选

大多数系统真正高频落地的，通常不是最后一行，而是前两到三行。

5.4 一个简单的选择原则

如果要把方案选择讲得更工程化，可以按下面这个顺序判断：

1. 能不能接受最终一致。
2. 能不能把跨服务动作改成事件驱动。
3. 失败后有没有明确补偿动作。
4. 是否需要冻结资源，而不是事后补偿。
5. 是否真的存在必须强一致且不能回滚补偿的场景。

通常可以概括成一句话：

能异步最终一致，就不要先上强一致；能补偿，就不要先上两阶段提交。

5.5 一个常见的落地方式：可靠消息最终一致

这个方案最常见，尤其适合订单、积分、通知、履约这类链路。

sequenceDiagram
    participant Order as 订单服务
    participant DB as 订单库
    participant Relay as 消息投递程序
    participant MQ as 消息队列
    participant Inventory as 库存服务
    participant Score as 积分服务

    Order->>DB: 本地事务写订单
    Order->>DB: 本地事务写 outbox
    DB-->>Order: 提交成功
    Relay->>MQ: 投递订单事件
    MQ-->>Relay: 发送确认
    Inventory->>MQ: 消费订单事件
    Score->>MQ: 消费订单事件
    Inventory->>Inventory: 幂等扣库存
    Score->>Score: 幂等加积分

这套方案的关键点不是“异步”本身，而是：

• 本地事务保证订单和待发送事件同成同败。
• MQ 保证事件可靠投递。
• 下游服务各自幂等。
• 失败时依靠重试、死信和对账补偿收敛。

5.6 TCC 更适合什么场景

TCC 的核心不是“比 Saga 更高级”，而是它要求业务本身能拆成：

• Try：预留资源
• Confirm：正式提交
• Cancel：释放资源

更适合的场景通常有：

但如果业务本身根本没有“预留资源”的自然语义，硬上 TCC 往往会把系统复杂度拉得很高。

5.7 Saga 更适合长流程编排

如果一个业务流程有很多步骤，例如：

1. 创建订单
2. 锁库存
3. 创建配送单
4. 发放优惠券
5. 通知用户

这类流程很适合拆成 Saga：

• 每一步都是本地事务
• 每一步都有对应补偿动作
• 某一步失败后，按逆序执行补偿

Saga 更关注的是“整条业务链怎么最终回到合理状态”，而不是所有步骤在一个瞬间同时成功。

5.8 一个订单、库存、积分的落地判断

假设下单流程包含：

• 订单服务创建订单
• 库存服务扣库存
• 积分服务发积分

更常见的落地思路通常是：

如果换成“支付扣款 + 冻结库存 + 核销余额”这种强业务约束场景，才更可能往 TCC 方向考虑。

5.9 常见误区

5.9.1 以为分布式事务只有 2PC 一种答案

实际互联网业务里，最常见的并不是 XA，而是可靠消息最终一致、Saga、TCC 这些更贴近业务现实的模式。

5.9.2 以为用了框架就自动一致

无论是 Seata 还是事务消息框架，都不能替代业务补偿、幂等、状态机和对账。

5.9.3 以为最终一致就不需要监控和补偿

最终一致不是“以后总会自己好”，而是必须靠重试、死信、补偿和对账把失败链路拉回来。

5.10 一段可直接复述的回答模板

分布式事务落地通常先按业务一致性要求选型，而不是直接背框架名。大多数互联网业务其实优先接受最终一致，所以像“本地写库后发事件”这类场景，通常会用本地消息表或者事务消息，解决 DB-MQ 一致性；下游再通过幂等、重试、死信和对账保证最终收敛。如果业务需要先冻结资源再确认，比如余额预扣、库存冻结，更适合 TCC。如果是长流程、多步骤并且每一步都能补偿，可以考虑 Saga。只有极少数不能接受最终一致、又确实需要强一致的场景，才会评估 XA / 2PC，同时接受它带来的性能和可用性代价。

5.11 小结

分布式事务真正要记住的不是几个名词，而是这条判断链：

• 先问业务要强一致还是最终一致。
• 能事件驱动就优先消息最终一致。
• 能补偿就优先补偿，不先上强一致。
• 需要预留资源再考虑 TCC。
• 极少数强一致场景才评估 XA / 2PC。

• Previous
  Java JVM 调优与 JDK8 GC 实战