消息中间件这个名词，现在基本可以算 Java 后端面试的必考题了。不管是应届生还是工作三五年的开发者，聊分布式、聊高并发、聊异步解耦，都绕不开这一块。我这些年参与技术面试，问过不少人消息中间件的问题，也见过很多候选人在这里翻车——问题本身不难，难在很多人只会背概念，一追问到细节就露馅。所以这篇东西把 Java 消息中间件面试题里最常出现、也最能拉开差距的知识点整理成一套答题思路，按可靠性、顺序性、幂等性、事务消息几条主线走一遍，适合正在准备 Java 后端面试的开发者，也适合想系统梳理消息中间件知识的人参考。

1. 先从面试官视角看：这类题到底在考什么

1.1 消息中间件不是八股文，而是分布式系统的必修课

很多候选人理解不了为什么面试官总爱问“你在项目里为什么用消息队列”。这个问题表面是在问技术选型，实际是在确认你有没有真正做过分布式系统。

现在的后端服务基本都拆成了微服务架构，服务之间不再是简单的 HTTP 同步调用，而是大量通过消息中间件做异步通信。消息队列解决的三个核心问题——异步、解耦、削峰——其实对应了分布式系统里最常见的三类痛点：接口响应太慢需要异步化；多个服务之间的强依赖需要解除；瞬时流量激增时系统扛不住需要削峰填谷。

我习惯用一个快递中转站的类比来解释这件事：没有消息队列的时候，生产者就像你直接把包裹送到收件人手里，对方不在家你就得一直等着，一次只能处理一个包裹。有了消息中间件，包裹先放到中转站，快递员收下就走了，收件人什么时候来取、让谁来取，那是中转站和收件人的事。生产者和消费者之间不需要同时在线，也不需要知道对方是谁，这就是解耦；包裹堆积在中转站慢慢派送，这就是削峰。

所以面试官问“消息中间件的使用场景”，不是让你背定义，而是想听你说清楚：哪个业务环节需要异步、哪些系统需要解耦、哪类流量需要削峰。能主动抛出自己项目里真实遇到过的场景，并且说清楚选型时的取舍，这道题的分数就不会低。

1.2 高频考点雷达图：可靠性、顺序性、幂等性、事务

消息中间件的面试题看着多，其实核心考点非常集中。我复盘这些年遇到过的问题，基本可以归纳成四类：

第一是可靠性，也就是消息不丢失。这类问题一般会从生产端、Broker 端、消费端三个环节拆开来问，每个环节都有不同的保证手段和配置参数。

第二是顺序性，比如同一个订单的创建、支付、完成消息必须按顺序消费，答不好就掉进“全局顺序”的坑里。

第三是幂等性，也就是消息重复消费怎么处理。面试官通常会设计一个场景，让你答出至少一到两种幂等方案。

第四是分布式事务，典型问题就是“RocketMQ 的事务消息是怎么实现的”“本地消息表和事务消息有什么区别”。

这四个主题背后，面试官真正想考察的是你在高并发、多副本、网络不可靠的真实环境里做技术取舍的能力。比如“消息不丢失”和“消息不重复”本身就是一对矛盾体，保证不丢往往意味着可能会重复，保证不重复往往意味着允许丢弃，如何权衡，才是高级工程师和初级工程师的分水岭。

还有一类高频问题属于底层原理，比如 Kafka 为什么快、刷盘机制、零拷贝、消费者重平衡。这类题目考察的是你是否理解消息中间件内部的工作机制，而不只是会用 API。

2. 基础概念题：协议、模型和选型对比

2.1 JMS、AMQP 和各家协议，别一听就懵

聊消息中间件，绕不开三个出现频率极高的名词：JMS、AMQP、以及各家中间件自己的协议。很多候选人在这一块概念是混乱的，上来就说“JMS 就是 ActiveMQ 的协议”“RabbitMQ 用的是 JMS”，全错。

JMS 是 Java 领域的一套消息服务规范，全称是 Java Message Service，它定义的是 API 层面的标准接口，比如 Connection、Session、MessageProducer、MessageConsumer。JMS 只面向 Java 语言，而且它只是一个规范，不是一个具体的传输协议。ActiveMQ 实现了 JMS 规范，但 JMS 不等于 ActiveMQ。

AMQP 则是一个应用层协议，全称是 Advanced Message Queuing Protocol，它定义的是消息传输的格式和交互流程，所以跨语言能力很强，Java、Go、Python、Node.js 都可以通过 AMQP 协议跟消息中间件通信。RabbitMQ 是 AMQP 协议最有名的实现，这也是 RabbitMQ 在企业级系统里受欢迎的原因之一。

Kafka 和 RocketMQ 则没有采用 JMS 或 AMQP，而是自己设计了基于 TCP 的二进制协议。为什么不用现成协议？因为 JMS 规范比较保守，事务消息、延迟消息、消息轨迹这类高级特性在 JMS 里并没有定义，Kafka 和 RocketMQ 想支持更多分布式场景，只能自己扩展协议。

面试官经常追问一个问题：为什么 RcoketMQ 不直接实现 JMS？你答“因为 JMS 没有事务消息和延迟消息，而且 Java 绑定太紧”就已经够了，如果还能补一句“RocketMQ 的消费模型是消费组模型，和 JMS 的发布订阅模型也有差异”，那这段就算完整了。

2.2 队列模型、主题模型、消费组模型

消息中间件有三种主流的消息模型，这是面试基础题里的基础，但很多人说不透。

第一种是点对点模型，也叫队列模型。一个队列里的每一条消息只会被一个消费者消费，消费完消息就从队列移除。这个模型最直观，但问题在于扩展性差：一个队列被多个消费者监听时，消息是竞争关系，如果想要广播，就得建多个队列。

第二种是发布订阅模型。一个 Topic 下的消息会被广播给所有订阅了该 Topic 的消费者，每个消费者都能收到同一条消息。这解决了广播问题，但没有“竞争消费”的概念，多个消费者实例会重复消费，无法水平扩展。

第三种是消费组模型，这是 Kafka 和 RocketMQ 采用的模型，也是面试最常深入的模型。它把消费者分为不同的 Consumer Group，同一 Topic 下的消息：

• 组内消费者竞争消费，一条消息只被组内一个实例消费；
• 不同消费组互不干扰，每个组都能收到完整的消息。

用生活例子理解：点对点模型就像公司食堂一份饭只能一个人领；发布订阅模型就像广播电台，谁都能收听；消费组模型就是一个小组里几个人分工抢单，但另一个小组同样能看到所有订单。

面试时如果能把消费组模型和前面两种模型区分开，并解释清楚为什么 Kafka 和 RocketMQ 都用消费组——因为它同时支持水平扩展和广播消费——这一题基本就稳了。

2.3 三大中间件怎么选，对比表与常见答题模板

面试中另一个高频问题是“Kafka、RocketMQ、RabbitMQ 你怎么选”。很多候选人的答案就是“Kafka 吞吐高，RabbitMQ 功能全”，太浅了。面试官想听的是结合场景的分析。

这里面有几个容易理解的误区和加分点：

• 选择 Kafka 通常是因为它把吞吐做到了极致，代价是功能相对简单，延迟消息、消息轨迹这些都不太完善，如果业务有订单这类需要精确事务的场景，直接选 Kafka 会给自己找麻烦。
• RocketMQ 的定位就是“能扛高吞吐同时要可靠”，事务消息和延迟消息都是原生支持，所以交易类系统用得很广。
• RabbitMQ 单机吞吐不高，但胜在协议标准、路由灵活，适合系统间集成场景。

面试答题模板可以这样组织：先复述一下业务背景和核心诉求，然后说“我当时对比了 Kafka、RocketMQ、RabbitMQ，因为业务有 XX 特点，最终选择了 XX”，一定要答出选型依据而不是直接背参数。如果没做过选型，可以拿一个虚拟场景来推演，比如“如果是一个订单支付系统，我会选 RocketMQ，因为它支持事务消息和延迟消息，而且吞吐也够”。

3. 可靠性：消息不丢的完整链路

3.1 生产端：acks 参数与 ISR 的关系

“怎么保证消息不丢失”是消息中间件面试里最经典的题目，答得好不好，很大程度上取决于你会发现这是一个三段式问题：生产端不丢、Broker 端不丢、消费端不丢。任何只答一段的答案，都会被追问到哑口无言。

生产端最容易丢消息的时机是网络超时和发送重试。Kafka 的生产者有一个关键参数 acks，它决定了什么时候算“发送成功”：

• acks=0：生产者发出去就不管了，只要发送动作成功就认为成功，消息可能已经在网络上丢了，这是最高吞吐但也最危险的配置。
• acks=1：分区 Leader 写入本地日志后立即返回成功，但这时候 Follower 还没同步，如果 Leader 宕机，这条消息就丢了。
• acks=all：生产者要求分区 ISR 中所有副本都写入成功后，才返回成功。这是可靠性最高的配置。

这里有个概念必须搞清楚：ISR（In-Sync Replicas）。每个分区有多个副本，其中 Leader 负责读写，Follower 负责同步，ISR 就是“和 Leader 保持同步的副本集合”。acks=all 的意思是“ISR 中的所有副本都收到消息才算成功”。

所以很多候选人认为只要设置了 acks=all 就万事大吉，这是个典型误区。如果某个分区的副本只有 Leader 一个在 ISR 里，比如其他 Follower 都挂了或同步落后被踢出 ISR，那么“ISR 中所有副本写入成功”其实等价于“Leader 一个写入成功”，消息照样可能丢。

正确的做法是：acks=all 配合 min.insync.replicas 参数。min.insync.replicas=2 表示 ISR 中至少要两个副本，否则生产者写入会报异常。这样即使 Leader 宕机，也还有副本持有数据，消息才不会丢。

生产端还有一个容易忽略的点：重试和顺序的关系。如果生产者默认开启重试，而同一分区同时有多个请求在途，第 N 条消息发送失败后重试，第 N+1 条消息可能已经发送成功，就会造成消息乱序。所以重试参数和 max.in.flight.requests.per.connection 需要配合设计，通常把在途请求数设置为 1，换取严格的顺序保障。

我这边给一个生产端配置的参考代码：

Properties props = new Properties(); props.put("bootstrap.servers", "node1:9092,node2:9092,node3:9092"); props.put("key.serializer", StringSerializer.class.getName()); props.put("value.serializer", StringSerializer.class.getName()); // 可靠性优先：等待所有副本确认 props.put("acks", "all"); // 最小同步副本数，配合 acks=all 才有意义 props.put("min.insync.replicas", "2"); // 不限制重试次数，消息没写入成功就一直重试 props.put("retries", Integer.MAX_VALUE); // 开启幂等发送，避免重试导致的重复消息 props.put("enable.idempotence", "true"); // 保证单分区顺序，限制在途请求数 props.put("max.in.flight.requests.per.connection", "1");

3.2 Broker 端：刷盘、副本与 PageCache

生产端把消息发到 Broker 后，消息还只是存在于内存或者操作系统 PageCache 里，如果进程宕机或机器断电，数据就可能丢。所以 Broker 端要解决的是持久化问题。

Kafka 和 RocketMQ 在持久化上的思路各有侧重。RocketMQ 默认采用异步刷盘，消息写入 PageCache 后立即返回给生产者，后台再定期把数据从 PageCache 刷到磁盘。异步刷盘性能高，但极端情况下会丢失少量消息。RocketMQ 也提供了同步刷盘模式，每条消息写入磁盘后才返回，可靠性更高但吞吐下降明显。

Kafka 则没有给用户提供同步刷盘选项，它的可靠性设计主要靠副本机制而不是单个节点刷盘。多副本前提下，即使一个 Broker 宕机，其他副本仍然持有数据。这也是 Kafka 能做高吞吐的原因之一：它牺牲了单机强一致，换取了跨机器的分布式可靠性。

理解了 PageCache 和顺序写，也就理解了为什么 Kafka 快。Kafka 的消息是追加写入磁盘的，也就是顺序写。顺序写磁盘的速度非常快，远远超过随机写。同时 Kafka 利用操作系统的 PageCache 机制，写入时数据先进 PageCache，读取时如果命中 PageCache 就不用访问磁盘。

面试官追问“为什么 Kafka 吞吐高”时，可以答这四个要点：分区并行、顺序写磁盘、PageCache 利用、零拷贝。其中零拷贝很多人只是听过名字，需要说清楚：传统的文件传输要经过用户态和内核态多次拷贝，Kafka 通过 sendfile 或 mmap 等方式减少了数据拷贝次数，让磁盘数据直接发送到网络缓冲区，大大提升了吞吐。

3.3 消费端：手动 ACK、offset 提交与三种语义

消费端消息丢失最常见的原因是：消费线程从消息中间件拉取了一批消息，在处理之前就提交了 offset，这时候消费者宕机或抛异常，这批消息就被认为已消费，实际业务处理却未完成，消息就丢了。

Kafka 消费者通过提交 offset 来记录消费位置。默认配置下，消费者是自动提交 offset 的，每过一段时间就自动提交一次。自动提交的坑在于：如果消息拉取后还没处理完，offset 就提交了，消费者重启后会从新 offset 开始消费，中间一批消息就永远错过了。

所以面试中谈到消费端可靠性，一定要落到手动提交 offset 上：拉取到消息后，先处理业务逻辑，只有处理成功后才提交 offset。

RocketMQ 的消费逻辑也是类似的，消费者拿到消息后，执行本地业务，返回 CONSUME_SUCCESS 表示处理成功，返回 RECONSUME_LATER 表示稍后重新投递。如果消费线程挂掉，消息会根据规则重试。

到这里，可以顺势引出消息投递的三种语义：

• at most once：最多一次，消息可能丢失但不会重复；
• at least once：至少一次，消息不会丢但可能重复，这是绝大多数消息中间件默认的语义；
• exactly once：精确一次，既不丢也不重复，实现代价极高。

实际生产中，几乎没人能在大规模分布式系统里做到真正的端到端 exactly once。更务实的方案是采用 at least once 语义，然后在消费端做幂等处理，最终达到业务层面的“精确一次效果”。

可靠性问题的标准答题框架，就是这三段：生产端设置 acks=all 和重试，Broker 端多副本和刷盘机制，消费端手动提交 offset 并在业务成功后记录。加上“消息丢失和重复是一对 trade-off”这句总结，这题能拿高分。

4. 顺序性和重复消费：两个最容易翻车的考点

4.1 顺序消息：全局顺序与分区级顺序的选择

面试官一旦抛出“怎么保证消息的顺序消费”，很多候选人就开始背“Kafka 通过 key hash 选择分区”这句话。但如果反向追问一句“那我要保证全局顺序呢”，往往会卡壳。

顺序分两种：全局顺序和局部顺序。

全局顺序意味着 Topic 下所有消息都按生产顺序消费，实现方式很简单：Topic 只设置一个分区，所有消息都进同一个分区，消费者单线程消费。但这样做的代价极大，分区数降为 1，吞吐能力大幅下降，分布式所带来的并行能力直接归零。所以真实业务里几乎不会用全局顺序，面试官问起来也更多是考察你对性能损耗的敏感度。

局部顺序才是实际用的方案：把需要保证顺序的消息，按照某个业务 Key 路由到同一个分区。比如同一个订单下的创建消息、支付消息、完成消息，都用订单号作为 Key，Kafka 对 Key 做哈希后选择分区，这样同一订单的所有消息都会进入同一分区；分区内消息是追加写的，天然有序，消费端只要处理得当，顺序就不会乱。

RocketMQ 的思路类似，发送消息时通过 MessageQueueSelector 把同一业务 Key 的消息选到同一个队列。面试追问“消费端开多线程会破坏顺序吗”时，要能答出来：即使消息在 Broker 端有序，如果消费端用多线程并发处理同一个分区的消息，顺序也可能乱。所以要么消费端单线程处理，要么按 Key 再做一层路由，让同一个 Key 的消息进入同一个消费线程。

4.2 重复消费是必然，幂等才是解题钥匙

“怎么保证消息不重复消费”这个问题，前提错了。在 at least once 语义下，重复消费不是一个概率事件，而是一个必然事件。至少有三个环节会导致重复：

第一，生产者重试导致 Broker 重复写入。生产端网络超时会触发重试，Broker 可能已经写入但应答丢失，重试导致同一条消息被写入两次。

第二，消费端处理成功但 offset 提交失败。消费者处理完业务，还没来得及提交 offset 就宕机，重启后消息被重新投递。

第三，消息中间件自身投递机制导致重复。比如 Kafka 消费者 poll 拉取一批消息，还没处理完就发生了 Rebalance，这批消息会重新分配给其他消费者，造成重复消费。

认识到了“重复是必然”，接下来面试官才会问重点：如何保证幂等。幂等是指同一个操作执行一次和执行多次，对业务状态的影响相同。

最常用、也最容易被接受的方案是数据库唯一约束。比如订单回调消息里带着订单号，处理时往订单状态表插入一条记录，订单号设置为唯一索引。第一次插入成功，第二次插入因为唯一键冲突失败，捕获异常后直接返回成功即可。这套方案不需要额外的中间件，落地简单。

第二种方案是 Redis 去重。用消息的唯一 ID 作为 Key，用 SETNX 判断是否已处理过。但这么做有一个隐患：Redis 高可用不如数据库，如果去重 Key 因为 Redis 宕机丢失，重复消息就可能穿透。所以 Redis 去重一般只做前置挡板，背后还要有数据库或状态字段兜底。

第三种方案是状态机校验。比如订单状态从“支付中”流转到“已支付”，消费消息前先查一下当前订单状态，如果已经是“已支付”，说明这条消息之前处理过，直接忽略。这种方式幂等效果很好，而且天然贴合业务语义。

4.3 幂等设计加分项：状态机与唯一键兜底

如果面试时只说到“用 Redis setnx 去重”，及格没问题，但想拿到加分，建议补上状态机设计。

幂等处理要区分两个层面：技术层幂等和业务层幂等。技术层幂等用消息 ID 或者 Redis 去重，解决的是系统层面重复调用的问题；业务层幂等用状态机，解决的是业务状态重复流转的问题。

实际生产里的做法通常是组合拳：先消费消息，用数据库唯一索引做第一层兜底，然后检查业务对象当前状态，如果业务状态机已经处于目标状态或后续状态，直接返回成功。这样即使唯一索引被删除，状态机依然能挡住重复消息。

还有一个很容易忽略的细节：幂等判断和业务处理必须在一个事务里。如果先判断“未处理”，然后执行业务逻辑，最后才写入处理记录，中间任何一步失败都可能导致不一致。正确顺序是：在同一个本地事务里，执行业务更新并插入去重记录，利用数据库事务保证原子性。这是做消息消费端幂等最重要的一条经验。

5. 事务消息与延迟消息：分布式最终一致性的经典答案

5.1 RocketMQ 事务消息：半消息与回查机制

分布式事务是消息中间件面试里的高级题，RocketMQ 的事务消息是其中最标准的答法。要理解事务消息，先要理解一个矛盾：如果把发消息和本地数据库事务放在一起，正确的顺序是什么？

先执行本地事务再发消息，本地事务成功但发消息失败，需要回滚本地事务，非常麻烦。先发消息再执行本地事务，消息发出去了但本地事务失败，消费者已经消费了不存在的业务操作，更混乱。

RocketMQ 的事务消息是这样解决的：

1. 生产者发送一条半消息到 Broker。半消息对消费者不可见，它只是暂时存储在 Broker 上。
2. Broker 存储半消息成功后，生产者执行本地事务，比如写订单库、扣库存。
3. 本地事务执行完成，生产者向 Broker 提交 COMMIT 或 ROLLBACK。COMMIT 后半消息变为可见消息，消费者可以消费；ROLLBACK 后半消息被删除。
4. 如果本地事务执行完但 Broker 一直没有收到 COMMIT 或 ROLLBACK，比如生产者发完半消息后宕机了，Broker 会启动消息回查，主动询问生产者这条消息对应的本地事务执行结果。生产者提供回查接口，根据业务数据返回 COMMIT 或 ROLLBACK。

这套机制的核心是半消息和回查。本地事务和消息的状态通过回查机制实现最终一致性，不会出现“业务成功了消息却没发出去”或者“消息发出去了业务却失败”的情况。

面试中画一张时序图讲清楚这四步，基本就掌握了事务消息的整个链路。追问也会集中在回查逻辑上：如果回查时生产者也没法判断本地事务状态怎么办？答案是根据业务幂等表查询，如果存在事务记录则提交，否则回滚，这也说明了事务消息的实现离不开业务侧的可查询能力。

5.2 本地消息表还是事务消息，怎么选

没有事务消息的老一代消息中间件，比如早期 RabbitMQ 和 Kafka，分布式事务问题怎么解决？面试官通常会给一个提示：还有一种方案叫“本地消息表”。

本地消息表的思路是：业务操作和写消息放到同一个数据库本地事务里。比如扣库存的同时往 local_message 表插入一条状态为“待发送”的消息记录，这两个操作在同一个事务里提交。之后有一个定时任务扫描本地消息表，把状态为“待发送”的消息发送到 MQ，发送成功后更新消息状态为“已发送”。如果发送失败，记录会一直留在表里，由定时任务重试。

本地消息表的好处是不依赖消息中间件的高级特性，理论上任何数据库和 MQ 都能用。缺点也很明显：第一，需要额外维护消息表，业务写在同一个库里，库的写入压力变大；第二，低峰期需要定时任务频繁扫描；第三，无法保证消息发送时序和业务时序严格一致。

和 RocketMQ 事务消息对比，本地消息表更像是“在业务侧手工实现事务消息”。事务消息把半消息管理和回查机制下沉到 Broker，业务侧只需要保证本地事务和 COMMIT/ROLLBACK 的返回逻辑正确，代码更简洁。

面试的加分回答是：“如果项目里已经用了 RocketMQ，优先用事务消息；如果用的是 Kafka 或者 RabbitMQ，本地消息表是更通用的兜底方案。两个方案的核心思想是一致的，都是把业务本地事务和消息发送绑定起来，用重试查来保证最终一致性。”

5.3 死信队列、延迟消息与消息积压的处理

除了事务消息，高并发场景下还有两个经常连带追问的点：延迟消息和死信队列。

延迟消息的典型场景是创建订单后 30 分钟未支付就自动关闭。如果不用消息中间件，一般方案是用定时任务扫描，但时间精度和数据库压力都是问题。RocketMQ 原生支持延迟消息，发送时指定延迟级别，到了延迟时间消息才能被消费者看到。RabbitMQ 没有原生的延迟队列，通常用“TTL + 死信队列”实现：给消息设置存活时间，超时后消息进入死信队列，消费者监听死信队列即可。Kafka 原生不支持延迟消息，需要自研或者用时间轮轮询，这也是有些项目即使知道 Kafka 吞吐高，但因为它缺延迟消息而选择 RocketMQ 的原因。

死信队列这个概念也常被问到。消息在消费失败重试多次后仍失败，或者消息过期，或者队列达到最大长度，这些消息会被投递到一个专门的队列，称为死信队列。死信队列存在的意义是：消息不能悄无声息地丢失，需要有一个地方让开发人员排查和补偿。面试时可以结合实际经验说：死信队列一定要配告警，否则时间长了没人看，死信就变成“死消息”了。

消息积压也是高频场景题。正确的处理思路是先区分积压原因：是生产端流量暴涨，还是消费端集群能力不足，还是消费者代码出现了阻塞。如果只是消费能力不够，不能盲目增加消费者，因为消费并行度受分区数限制。一个分区最多被一个消费者实例消费，消费者数量大于分区数时，多余的消费者只能闲置。正确做法是先适当增加分区数，再扩容消费者，或者临时写脚本把积压消息转发到临时队列，用临时消费者集群快速处理。这类场景题没有唯一标准答案，面试官看的是你有没有真的在线上处理过积压问题。

6. 高频追问现场还原与答题策略

6.1 十分钟速查：十个消息中间件面试题

我整理了十个出现频率最高的消息中间件面试题，每个题给出简洁的标准答案，适合面试前一天快速回顾。

这十个问题如果都能闭着眼睛答出层次，基础面基本没有大问题。

6.2 几个容易踩的坑与反直觉的点

面试时最容易翻车的不是答不上来，而是答了一个“听起来正确但经不起追问”的答案。我挑几个最典型的。

第一个坑：说自己项目里用的是 Kafka，但问到可靠性就只答“acks=all”。追问“如果 ISR 里只有一个副本怎么办”，哑口无言。Kafka 的可靠性需要 acks=all 和 min.insync.replicas 一起生效，这是很多人不知道的细节。

第二个坑：用 Redis 做幂等去重，认为是万无一失的。追问“Redis 宕机怎么办”，就答不上来了。幂等设计不能单一依赖非持久化存储，数据库唯一约束或状态机才是兜底。

第三个坑：说消息积压后“多加几个消费者就行”。分区数是消费并行度的天花板，消费者数量超过分区数没有意义。正确做法是评估分区数是否需要扩容。

第四个坑：混淆 at least once 和 exactly once。很多候选人说“Kafka 支持精确一次”，然后解释不出跨系统精确一次和多系统之间的限制。Kafka 的精确一次更多是在生产端幂等发送和消费端事务读写的有限场景下成立，跨多个外部系统的端到端精确一次目前仍然是一个需要靠幂等补偿才能实现的目标。

第五个坑：介绍 RocketMQ 事务消息，只知道“半消息”这个名词，不知道回查机制。回查才是事务消息的灵魂，没有回查，半消息就卡死在不可见状态，本地事务就永远悬空。

6.3 准备建议：动手搭一套环境比背题有用

说句实在话，消息中间件面试题光靠背是背不出来的，因为面试官只要多追问一层，背到的东西就会露馅。建议大家准备时，一定要动手搭一套环境做几组实验。

在本地用 Docker 起一个 Kafka 或 RocketMQ，然后自己制造故障：把生产者的 acks 改成 0，看看消息是不是真的会丢；把消费者改成自动提交，然后在处理前杀掉进程，看看重启后是不是丢了消息；用同一个 Key 发 10 条消息，消费端开多线程，看看顺序是不是会乱。

这些实验做完，你会对“消息不丢、不重、不乱”有非常深的肌肉记忆，面试时不需要刻意背，答案自然就从项目经验里出来了。

我面试候选人的时候，最怕的不是答得不够全，而是全程只有结论没有过程。一问“你的消费端是怎么保证幂等的”，能连业务代码的异常处理都讲出来的人，和只背“用 Redis 做去重”的人，差距一眼就能看出来。所以准备的核心是把每个结论都变成自己亲手验证过的经验，哪怕只是一个小 demo，也远比刷十篇面经有用。

顺着可靠性、顺序性、幂等性、事务消息这条主线，把每个问题都写成自己的版本，再找人模拟追问一轮，基本就稳了。如果项目里暂时用不到消息中间件，也可以用本地环境模拟真实场景，观察消息从生产到消费的完整生命周期——这一步做完，这类面试题对你来说就真正变得“可回答”了。