阿里面试高频题：订单系统十万TPS如何确保MQ消息不重复消费

时间：2026-06-27 14:32

MQ的Exactly-Once是分布式开发的核心考点，也是实际工作中高并发订单系统的必踩坑点，不少人就栽在「只看消费端，忽略全链路」这个思路上。在分布式系统里待久了都知道，MQ是高并发订单系统的标配，而消息仅消费一次（Exactly-Once）绝对是大厂面试的必考题。尤其是被问到「10万+TPS峰

MQ的Exactly-Once是分布式开发的核心考点，也是实际工作中高并发订单系统的必踩坑点，不少人就栽在「只看消费端，忽略全链路」这个思路上。

在分布式系统里待久了都知道，MQ是高并发订单系统的标配，而消息仅消费一次（Exactly-Once）绝对是大厂面试的必考题。尤其是被问到「10万+TPS峰值下，怎么保证订单消息只消费一次，避免重复扣库存」，很多人张口就来「消费端做幂等就行」，结果被面试官连环追问怼到哑口无言，面试直接凉凉。

为什么？因为这个问题的核心根本不是单靠消费端，而是生产端→中间件→消费端的全链路保障，还要兼顾高并发的性能。今天就把阿里面试官认可的标准答案掰开揉碎讲，从避坑指南到全链路方案，再到可直接套用的面试模板。看完这篇，再被问到这个问题直接稳了。

一、大厂面试踩坑现场！这些错误千万别犯

先看一个典型的失败回答，看看你是不是也这么说的：

面试官：我们项目用RocketMQ处理高并发订单消息（峰值TPS 10万+），如何保证每个订单消息只被消费一次，避免重复扣库存？

候选人：只要在消费端做幂等就行：给每个消息加唯一ID，消费前查数据库有没有处理过，没处理过就扣库存，处理过就跳过，这样就算消息重复了也不会重复消费。

3大致命错误，直接被面试官判卷0分：

❌忽略全链路风险：只谈消费端幂等，没解决生产端重试多发、中间件故障重投的问题，就算消费端能去重，也会浪费MQ存储和消费端资源，高并发下性能直接拉胯。
❌幂等方案不落地：只说查库判断，没考虑10万+TPS下频繁查库的性能瓶颈，也没说唯一ID怎么生成、去重表怎么设计，纯理论无实操。
❌没结合高并发特性：忽略了消息乱序、消费端集群部署的并发控制问题，方案放到实际场景里直接失效。

说白了，很多人都陷入了「只要做好消费端幂等，一切问题都解决了」的误区，却忘了生产端、中间件的风险才是源头。

二、先搞懂核心：Exactly-Once的本质是啥？

不管是不是高并发场景，要保证消息只被消费一次，核心就解决两个问题：消息丢失和消息重复，而且必须覆盖生产端→中间件→消费端全链路，任何一个环节出问题，前功尽弃。

✅消息丢失：生产端没发出去、中间件没存住、消费端没接到，结果就是用户下单了没扣库存，业务漏处理。
✅消息重复：生产端重试、中间件重投、消费端未确认重发，结果就是用户下单扣两次库存，业务出bug。

而高并发场景下这两个问题会被无限放大：生产端为了抗高并发，用异步+重试，极易重复发送；中间件用分区并行存储，节点故障重启就会重投未确认消息；消费端用集群+多线程处理，容易出现「消费成功但Offset没提交」的情况，导致重复消费。

一句话总结：高并发下的Exactly-Once，是防丢失+防重复的全链路保障，而非单一环节的补救。

三、全链路拆解：10万+TPS下的防丢防重方案

按生产端→中间件→消费端的顺序，针对每个环节的高并发风险，设计专属解决方案，同时兼顾性能，避免保障机制拖垮TPS。全程以RocketMQ/Kafka为例，实操性拉满。

1. 生产端：从源头确保「消息不丢、不重复发」

生产端是消息的起点，这一步没做好，后面再怎么补救都是白搭。

(1) 核心风险

异步发送时网络波动，没收到MQ确认，重试导致重复发送。
生产端进程崩溃，消息没发出去直接丢失。
消息生成速度超过发送速度，导致积压/丢失。

(2) 高并发解决方案

① 唯一消息ID + Redis集群幂等表，防重复发送

这是生产端防多发的核心，全程不阻塞主流程，适配高并发：

生成消息时，创建全局唯一ID（雪花ID/UUID+订单号，带业务标识更易排查）。
用线程池异步往Redis幂等表写入状态（Key=消息ID，Value=发送中/已发送，过期24h），不阻塞消息生成。
调用MQ的同步发送接口（sendSync），等待Broker确认。
收到确认则更新Redis为「已发送」；超时/失败重试前，先查Redis状态：已发送则停止，发送中则等待100ms再查，避免并发重试。

✅ 高并发优化：Redis集群哈希分片，避免单点压力；异步写入，不影响主流程TPS。

② 事务消息，保证业务与消息发送一致性

适用场景：需要先创订单，再发扣库存消息的核心业务，避免「订单创建成功消息丢了」或「消息发出去订单创建失败」。

以RocketMQ为例：

生产端先发送半消息（Broker接收后标记为不可消费）。
执行本地业务操作（如订单入库）。
业务成功则发确认消息，Broker将半消息标为可消费。
业务失败则发回滚消息，Broker删除半消息。
若生产端崩溃，Broker会定时回查事务状态，避免消息积压。

✅ 高并发优化：回查接口做缓存，避免频繁查库；半消息按Broker分区存储，提高并行处理能力。

2. 中间件：承上启下，确保「消息不丢、不重复投」

MQ中间件是消息的中转站，这一步要做好存储和投送的把控，避免消息丢了或乱投。

(1) 核心风险

Broker磁盘满/节点崩溃，消息直接丢失。
消费端没确认消费成功，Broker无限重试投送，导致重复。
高并发下消息积压，投送速度跟不上，消费延迟。

(2) 高并发解决方案

① 持久化 + 副本机制，从存储层面防丢失

开启同步刷盘：RocketMQ用SYNC_FLUSH，Kafka用acks=all，确保消息落盘后再返回发送成功，避免内存断电丢失。
开启副本机制：RocketMQ主从复制，Kafka分区副本，每个消息至少存2个副本，主节点故障从节点无缝顶替，避免单点丢失。
定期清理过期消息（如7天），避免磁盘满导致新消息无法写入。

✅ 高并发优化：Broker用SSD磁盘，提升刷盘速度；副本同步用「异步复制+定时校验」，平衡性能与一致性。

② 拉取式消费 + 手动Offset提交，防重复投送

采用拉取式消费（而非推送式）：消费端根据自身处理能力按需拉取消息，避免Broker盲目推送导致重复。
手动提交消费偏移量（Offset）：消费端处理完消息后，再调用ackMessage（RocketMQ）/commitSync（Kafka）提交Offset，处理失败则不提交，Broker下次重投。
限制重试次数（如最多16次），超过次数的消息放入死信队列，避免无限重试浪费资源。

✅ 高并发优化：Offset批量提交（如每处理100条提交一次），减少网络请求；死信队列定期清理，释放存储资源。

3. 消费端：最终保障，确保「消息不重复处理、不遗漏」

消费端是消息的终点，这一步的核心是幂等处理+并发控制，既要防重复，又要扛住高并发。

(1) 核心风险

消费端多实例并发消费同一消息，导致重复处理。
消费成功但Offset没提交，Broker重投导致重复。
查库判断幂等的性能瓶颈，导致消费TPS上不去。

(2) 高并发解决方案

① 结合业务选「高效幂等方案」，拒绝查库性能瓶颈

幂等的核心是「同一消息处理多少次，结果都一样」，3种方案按需选，全适配高并发（如下表）。

（注：原文此处应有一张表格，但原文以文字描述“直接看表”并提及了表格内容，但未提供具体表格。保持原文表述：原文说“直接看表?”，但实际图片中无表格，故保留文字说明。）

② 并发控制 + Offset原子管理，从流程防重复

采用集群消费模式：同一Topic的不同分区分配给不同消费实例，同一分区仅一个实例消费，从源头避免多实例抢消息。
用线程池+队列缓冲消息：控制并发数（如每实例20线程），动态扩容（根据积压数调整），避免线程耗尽导致处理失败。
Offset原子提交：将「业务处理+Offset提交」放入同一事务（如Spring @Transactional），确保处理成功必提交、处理失败不提交。
若用Redis去重，将「写入去重表+提交Offset」设为原子操作。

四、阿里面试标准答案！直接背走，怼赢面试官

被问到这个问题，不用慌，按全链路保障+高并发优化的逻辑回答，结构清晰，落地性强，面试官直接给高分。

1. 标准答案模板（可直接口述）

面试官您好，高并发场景下（10万+TPS）保证MQ消息只被消费一次，核心是解决全链路的消息丢失与重复问题，需从生产端、中间件、消费端三个环节设计防丢防重方案，同时每个环节做高并发性能优化，避免保障机制拖垮TPS，具体方案如下：

(1) 第一，生产端从源头确保消息不丢、不重复发

用「全局唯一消息ID + Redis集群幂等表」防多发：生成消息时异步写入Redis状态，重试前先查Redis，避免重复发送；Redis做哈希分片，线程池异步写入，不阻塞主流程。
核心业务用RocketMQ事务消息保一致性：先发送半消息，业务操作成功后确认消息，失败则回滚，Broker定时回查事务状态，避免生产端崩溃导致消息积压。

(2) 第二，中间件承上启下确保消息不丢、不重复投