消息队列 面试题

1. Kafka 高吞吐量设计

❓ 题目： Kafka 是如何实现高吞吐量的？从存储架构、网络模型、消费模型三个角度分别说明。

追问1：Kafka 的零拷贝（Zero Copy）是什么意思？它和传统的四次拷贝两次 CPU 拷贝有什么区别？ 追问2：Kafka 为什么能做到百万级消息堆积而不影响性能？这和传统的 RabbitMQ 有什么根本区别？

💡 答案：

主问题： Kafka 的高吞吐量来源于设计上的多个关键决策。存储架构方面，Kafka 采用顺序写入磁盘的方式——数据以日志方式追加到文件末尾，充分利用磁盘的顺序写性能（机械盘顺序写 100MB+/s，接近随机写的几十倍），避免了传统消息队列频繁随机 IO 的问题。日志文件按 segment 分段存储，便于清理过期数据。网络模型方面，Kafka 大量使用零拷贝技术——Producer 到 Broker 和 Broker 到 Consumer 的数据传输都尽可能避免不必要的数据复制和 CPU 参与，直接从文件系统缓存发送到网络。消费模型方面，Kafka 采用 Pull 模式——消费者根据自己的处理能力拉取消息，避免了 Push 模式下消费者来不及处理造成的消息积压和 OOM，同时支持批量拉取减少网络往返次数。另外日志压缩（Compaction）和分区并行也是一个重要因素——一个 Topic 可以有多个分区，每个分区可以由独立的 Broker 负责，生产和消费可以在分区级别实现完全并行。

追问1： 零拷贝的核心是”不使用 CPU 在内核空间和用户空间之间拷贝数据”。传统方式下从磁盘文件发送到网络需要：磁盘 → 内核缓冲区（DMA 拷贝，1次）、内核缓冲区 → 用户空间（CPU 拷贝，2次）、用户空间 → Socket 缓冲区（CPU 拷贝，3次）、Socket 缓冲区 → 网卡（DMA 拷贝，4次），总共四次拷贝两次 CPU 参与。Kafka 利用 Linux 的 sendfile 系统调用（底层用 splice 或 DMA Scatter/Gather）：磁盘 → 内核缓冲区（DMA 拷贝）、内核缓冲区 → 网卡（DMA 拷贝），数据从磁盘到网卡完全在内存中的”页面”级别完成，CPU 不必参与数据搬运，只有两次 DMA 拷贝。这个优化对性能影响巨大——在 100Gb 网卡上，没有零拷贝的话 CPU 很快就成为瓶颈。Java 中 FileChannel.transferTo 底层就使用了 Linux 的 sendfile（取决于操作系统支持）。

追问2： 根本区别在于存储模型。RabbitMQ 每个消息都带有很多元信息来管理消息的确认、重试、过期等复杂逻辑，消息存储在内部数据库中，大量堆积时这个索引数据库的性能急剧下降。而 Kafka 的消息存储本质上是 append-only 日志文件 + 一个 index 索引文件（稀疏索引，非密集索引），Consumer 只需要记录自己消费到的 offset 位置。堆积对 Kafka 的影响仅仅是磁盘占用增加，而顺序读写的性能基本不受数据量影响。RabbitMQ 的消息每一条是独立存储、独立管理的，处理完后删除；Kafka 的消息按分区整体管理，以 segment 为单位过期删除——Consumer 只是给偏移量”挪了一下指针”，这个操作的成本是常量级的。所以”堆积 100 万条消息”在 Kafka 中是对性能几乎没有影响的，在 RabbitMQ 中则是管理负担随消息量线性增长。

📌 易错点 / 加分项：

  • 零拷贝不适用于需要修改数据的场景（如加密压缩），Kafka 只在不需要修改的传输路径上使用
  • Kafka 的分区数不是越多越好——分区越多，元数据更新开销、Leader 选举等成本越高
  • Producer 的 acks=all 配合 min.insync.replicas 是消息不丢失的关键配置

2. Kafka 消息不丢失与重复消费

❓ 题目： Kafka 如何保证消息不丢失？从 Producer、Broker、Consumer 三个角色分别说明。

追问1：消息已经保证”不丢失”了，为什么还会”重复消费”？什么样的业务场景需要做幂等处理？ 追问2：Kafka 的事务消息解决了什么问题？和 RocketMQ 的事务消息有什么不同？

💡 答案：

主问题： 消息不丢失需要三个角色的配合。Producer 端：acks 配置决定消息发送的确认级别——acks=0 发完不管、数据可能丢失；acks=1 等待 Leader 确认，如果 Leader 宕机但 Follower 未同步完则数据丢失；acks=all（或 -1）需要 Leader + 所有 ISR 中的副本确认，同时配合 min.insync.replicas 保证至少有 N 个副本存活，最大限度保证不丢。此外 retries 设为大于 0 的值启用重试，enable.idempotence=true 开启生产者幂等避免网络故障导致的重复写入。Broker 端：replication.factor 大于 1 且 min.insync.replicas 至少 2，保证有副本；unclean.leader.election.enable=false 禁止 ISR 之外的副本竞选 Leader（宁可不可用也不丢数据是很多金融业务的默认选择）。Consumer 端：禁用自动提交（enable.auto.commit=false），在业务处理完成后手动提交 offset（commitSync），保证”处理一条、提交一条”，而不是”消费一条、提交一条但处理失败了”。

追问1： 消息不丢失和重复消费是两个维度的问题。“不丢失”保证的是数据至少到达一次（At-Least-Once），但无法保证精确一次（Exactly-Once）。重复消费的根源：Producer 端发送消息后网络超时，Producer 以为失败了于是重试，但其实 Broker 已经写入成功——Broker 中存了两条相同的消息。Consumer 端在处理完消息后准备提交 offset 的时候进程挂了，重启后从上一次提交的位置重新消费，导致 Consumer 重复处理。所以幂等处理是业务必须自己实现的——比如用数据库唯一键约束兜底（INSERT ... ON DUPLICATE KEY UPDATE）、Redis 的 setNX、或者给每条消息分配唯一的业务 ID 在消费前先查是否已处理过。

追问2： Kafka 的事务消息（自 0.11 版本引入）主要解决”consume-transform-produce” 模式的原子性问题——比如从 Topic A 消费一条消息并处理后写入 Topic B，需要保证”读取 + 处理 + 写入”是一个原子操作，如果处理失败，消息的消费 offset 不提交同时不写入 Topic B。Kafka 通过 transaction coordinator 和两阶段提交实现，配合 isolation.level=read_committed 消费者只读已提交的事务消息。RocketMQ 的事务消息解决的是”本地事务 + 发送消息”的原子性——先发一个 half 消息（对消费者不可见），执行本地事务，根据本地事务结果再决定是提交还是回滚 half 消息。典型的场景是”下单扣库存，同时发消息通知其他服务”——本地事务扣库存成功、发消息确实成功；如果本地事务失败，half 消息回滚。这是 RocketMQ 最经典的差异化能力，Kafka 不提供这种内置的事务模式。

📌 易错点 / 加分项：

  • acks=all 不等于不丢消息——ISR 中只有一个节点且 min.insync.replicas=1，宕机仍可能丢
  • enable.auto.commit 是反模式——消费者在 poll 时自动提交，如果 poll 和业务处理之间发生异常数据就丢了
  • Kafka 事务的代价是吞吐量下降约 15-20%，不是所有场景都要开

3. RocketMQ 架构与事务消息

❓ 题目： RocketMQ 的整体架构是怎样的？NameServer 和 Kafka 的 ZooKeeper 有什么不同的设计哲学？

追问1：RocketMQ 的延迟消息是如何实现的？延迟级别可以任意设置吗？ 追问2：RocketMQ 的事务消息”回查机制”是什么？为什么要回查？

💡 答案：

主问题： RocketMQ 的架构由 NameServer、Broker、Producer、Consumer 四部分组成。NameServer 是整个集群的”路由注册中心”，每个 Broker 启动时注册到所有 NameServer，Producer 和 Consumer 定期从 NameServer 获取 Topic 的路由信息（该 Topic 落在哪些 Broker 上）。NameServer 之间不通信，是完全对等的节点，没有主从关系——这跟 ZooKeeper 的设计理念完全不同。ZooKeeper 通过 ZAB 协议保持集群一致性，能作为分布式协调的基础设施；NameServer 是”最终一致性”的——Broker 定时心跳上报，NameServer 之间不同步，如果一个 NameServer 挂了，不影响其他 NameServer 及其上的路由信息。这种设计使得 NameServer 极其轻量、易部署，适合 RocketMQ 的”路由信息变化不频繁且允许短暂不一致”的场景。Kafka 在 3.x 版本后也逐步去 ZooKeeper 依赖（KRaft 模式），方向上也是认为”为消息系统引入一个强一致性协调者太重”。

追问1： RocketMQ 的延迟消息不是任意的——它预设了一系列延迟级别 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h（共 18 个级别，商业版可以更多）。实现原理是：Broker 收到延迟消息后不直接投递给 Consumer，而是按延迟级别分到对应的内部延迟队列中，通过定时任务检查——当消息的延迟时间到了，将其移到真正的消费队列中等待 Consumer 拉取。由于只支持固定级别，延迟队列数有限（18 个），定时器只需轮询这 18 个队列即可。不能任意设置的原因是：如果支持任意时间，延迟队列数量会爆炸，定时器的检查成本不可控。但如果业务需要精确的延迟（比如 17 秒后发消息），就需要自己在上层封装——先算最近可用的延迟级别，在消费者端再判断是否满足精确时间要求。

追问2： 回查机制是 RocketMQ 事务消息的核心保障。流程是：Producer 先发 half 消息成功，然后执行本地事务。如果本地事务执行成功，Producer 向 Broker 发送 Commit 请求。但如果本地事务执行过程中 Producer 挂了或网络中断，Broker 永远收不到 Commit/Rollback——此时 half 消息的状态是 Unknown。回查机制：Broker 定期扫描 Unknown 状态的事务消息，主动回查 Producer 端，调用 Producer 注册的回查接口 checkLocalTransaction()，让 Producer 去检查本地事务到底成功了没有（比如查一下数据库那个订单创建了没有），然后确定 commit 还是 rollback。需要回查的根本原因是：分布式环境下，“发送 Commit”这个动作本身可能因为网络原因没有到达 Broker，需要有一个独立的路径来确认事务的最终状态。

📌 易错点 / 加分项：

  • NameServer 是无状态、可水平扩展的——部署两个足够了，多了反而没必要
  • RocketMQ 的延迟消息是”近似延迟”——如果一条延迟消息所在队列积压严重，实际延迟可能比预设级别更长
  • RocketMQ 事务消息不是所有业务都适合——回查逻辑的复杂度需要业务方配合