Kafka面试高频16问：从原理到实战解析

很多人在准备 Kafka 面试时，习惯把网上零散的面试题背一遍，结果真正被问到原理、追问、场景设计时，还是接不住。尤其当面试官把同一个问题从“是什么”问到“为什么”，再问到“线上遇到怎么办”，大多数人会卡在第二层。

这篇内容围绕 Kafka 面试里出现频率最高的 16 个核心问题展开，从架构原理、生产端可靠性、消费端语义、性能优化到集群运维，每个问题都给出通俗解释、原理拆解和面试回答要点。不追求“背答案”，而是帮你建立一套可以应对追问的知识体系。无论你是刚开始看 Kafka，还是准备跳槽冲刺，这份内容都值得认真过一遍。

1. 面试前的定位：Kafka 到底在问什么

1.1 Kafka 为什么是面试高频

Kafka 已经是后端技术栈里几乎绕不开的中间件。企业对候选人的考察，往往不只是“会不会用”，而是“有没有真正在项目里落地过”。所以 Kafka 面试题通常会覆盖几类：

• 基础概念题：Kafka 是什么、有哪些组件、和别的消息队列有什么区别。
• 原理理解题：分区、副本、ISR、HW、LEO、日志存储。
• 可靠性问题：如何保证消息不丢失、不重复、不乱序。
• 性能问题：Kafka 为什么快，支撑高吞吐的核心机制是什么。
• 运维问题：消息堆积、集群宕机、版本升级、消费延迟高怎么处理。

这些内容看起来多，但核心都围绕一条主线：消息从生产端到消费端，中间经过 Kafka 集群，每一环如何保证数据可靠、高效、有序。顺清楚这条链路，16 问基本能串起来。

1.2 这 16 问怎么用

建议先花一天把文章里的原理问题读懂，第二天自己动手在本地或者测试环境起一个 Kafka 实例，把生产、消费、查看堆积这些命令跑一遍。第三天再针对每个问题做输出练习，也就是不看答案，用自己的话讲一遍。这样做比单纯刷题有效得多。

文章里的每道题都会按“一句话结论 + 原理拆解 + 面试怎么答”的方式展开，方便你在短时间内建立答题框架。

2. 架构与核心概念：先打地基

2.1 第 1 问：Kafka 是什么？和 RocketMQ、RabbitMQ 有什么区别

一句话结论：Kafka 是一个分布式、基于发布订阅模式的消息队列，主要特点是高吞吐、低延迟、可持久化、支持水平扩展。

面试时不要只背这句话，要能解释它为什么高吞吐。Kafka 的设计思路是：把消息顺序追加到分区文件里，利用 Page Cache 和顺序写磁盘来提升性能；消费时通过消费者组并行消费；数据写入多个副本保证可靠性。这些设计决定了它和传统消息队列的定位差异。

对比方面，可以从几个维度来说：

面试回答时，重点强调 Kafka 的定位是“分布式日志提交系统”，它把消息当成不可变的数据流来存储，所以天然适合数据集成和流处理。不要死记表格，能说出核心差异即可。

2.2 第 2 问：Broker、Topic、Partition、Consumer Group 到底是什么

这是一个连环追问的高发区。很多人能说出名词，但说不清它们之间的关系。

Kafka 集群由多个 Broker 组成，一个 Broker 就是一个 Kafka 服务节点。Topic 是消息的逻辑分类，比如订单消息、日志消息。一个 Topic 可以拆成多个 Partition，Partition 是物理上的有序日志文件，每条消息在分区内都有一个唯一的偏移量 Offset。

Consumer Group 是消费端的分组机制。同一个 Group 内的消费者共同消费一个 Topic 的消息，一条消息只能被同组内的一个消费者实例消费。不同 Group 之间互不影响，都能消费到同一份完整数据。

面试官经常追问：为什么 Kafka 要设计分区？

回答思路是：分区解决了两个问题。一是并行度，一个 Topic 的数据如果只放在一个文件里，读写都会成为瓶颈；拆成多个分区后，生产者和消费者都可以并行读写。二是水平扩展，分区可以分布在不同 Broker 上，集群扩容时可以把分区迁移到新节点。

2.3 第 3 问：分区副本机制：Leader、Follower、HW、LEO 的关系

副本机制是 Kafka 高可用的基础。每个分区可以有多个副本，副本分为 Leader 副本和 Follower 副本。

• Leader 负责处理读写请求。
• Follower 只负责从 Leader 同步数据，不对外提供服务。
• LEO（Log End Offset）表示每个副本日志最后一条消息的下一条位置。
• HW（High Watermark）表示已经同步给所有 ISR 副本的最大位移，消费者只能消费 HW 之前的数据。

这里有个容易混淆的点：Kafka 的副本机制不是强同步，而是“ISR 内副本同步完就算成功”。写入时不需要等所有副本都返回，只需要 ISR 列表里的副本同步完成即可。

面试常追问：Leader 挂了怎么办？

回答思路：Kafka 会在 ISR 列表中选择一个副本作为新的 Leader。ISR 是“同步中副本”的集合，如果某个 Follower 长时间没有追上 Leader 的消息，会被踢出 ISR。之所以优先从 ISR 选 Leader，是因为它的数据最完整，可以避免数据丢失。

更深一层的追问是：如果 ISR 里所有副本都挂了怎么办？这就要提到 Kafka 的 unclean.leader.election 配置。默认关闭，此时分区不可用，但保证不丢数据；如果开启，可以从非同步副本中选出 Leader，分区可用但可能丢数据。生产环境通常建议关闭。

3. 生产者与消息可靠性

3.1 第 4 问：生产者发送消息的完整流程

这个问题考察的是对生产端工作过程的整体认识。

完整流程可以概括为：

1. Producer 根据分区器决定消息写入哪个分区。
2. 消息先进入 Producer 客户端的缓冲区，由发送线程批量发送。
3. Broker 收到消息后写入分区日志，并根据配置决定是否返回确认。
4. Producer 收到确认后，可以认为消息发送成功。

这里面有两个容易被问到的细节。

第一个是分区策略。默认分区器按 Key 的 Hash 值取模选定分区；没有 Key 时，采用粘性分区策略，会尽量把多条消息发送到同一个分区，减少请求次数。

第二个是批量发送。Producer 不是一条一条发送消息，而是攒一批再发。相关参数有 batch.size 和 linger.ms。batch.size 表示一批消息的最大字节数，linger.ms 表示最多等待多长时间。这两个参数直接影响吞吐量和延迟。

面试时可以用一个简单的代码片段辅助说明：

// 文件路径：src/main/java/com/example/kafka/ProducerSample.java Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); // 启用幂等 props.put("enable.idempotence", true); // 等待所有副本确认，结合幂等可保证不丢不重 props.put("acks", "all"); props.put("retries", 3); // 批量参数 props.put("batch.size", 16384); props.put("linger.ms", 5); KafkaProducer<String, String> producer = new KafkaProducer<>(props); producer.send(new ProducerRecord<>("test-topic", "key-1", "value-1")); producer.close();

注意：这里的参数在较新版本中建议使用 ProducerConfig 常量，避免魔法字符串。示例重点是流程演示，需要根据实际 Kafka 客户端版本调整。

3.2 第 5 问：acks 参数 0/1/-1 怎么选

acks 是生产端最重要的可靠性参数之一，面试官几乎必问。

• acks=0：Producer 不等待 Broker 确认，直接认为发送成功。延迟最低，但消息可能丢失，适合日志采集等允许丢失少量数据的场景。
• acks=1：Leader 写入成功后返回确认。默认配置，兼顾性能和可靠，但 Leader 崩溃时，未同步给 Follower 的消息会丢失。
• acks=-1 或 all：ISR 内所有副本都同步成功后才返回。可靠性最高，但延迟也最高。

面试时要把 acks 和 min.insync.replicas 放在一起说。如果设置 acks=all，但 min.insync.replicas=1，那么只有 Leader 一个副本同步时也算成功，可靠性约等于 acks=1。生产环境一般建议：

acks=all min.insync.replicas=2

这样表示至少有两个副本同步成功，Broker 才会返回确认，能有效降低 Leader 崩溃时的消息丢失风险，前提是集群里每个分区至少保有 3 个副本，并且实际可用副本数满足 2 个以上。

3.3 第 6 问：幂等性与事务机制

在开启幂等性后，Producer 会为每条消息生成序列号，Broker 端会检查序列号，如果重复则拒绝写入，从而避免消息重复。幂等性本质上解决的是“Producer 重试导致的消息重复”。

面试时会追问：幂等性有什么限制？

需要回答：幂等性只在单分区内有效，而且只能保证单次会话内不重复。如果 Producer 重启，序列号状态会丢失；如果消息分布到多个分区，幂等性无法跨分区保证。

跨分区或者跨会话的严格不重不漏，需要用到 Kafka 事务。Kafka 事务通过 Transaction Coordinator 协调，支持把多条消息原子地写入多个分区。生产环境真正用到事务的场景并不多，因为事务会引入额外开销，通常会优先考虑消费端幂等方案来兜底。

这里要特别注意：面试官问“消息重复怎么办”时，不要把生产端幂等和消费端幂等搞混。生产端幂等只是减少生产重复，消费端的重复消费依然要靠业务侧解决。

3.4 第 7 问：Kafka 如何保证消息不丢失

这是 Kafka 面试题里的核心问题，基本属于必考题。回答时要从三个端分别说明：

生产端：

• 设置 acks=all，确保 ISR 副本同步完成。
• 开启 retries，允许发送失败重试。
• 开启幂等性 enable.idempotence=true，避免重试导致重复。
• 使用异步发送时，要处理回调中的异常，不能只 send 不关心结果。

Broker 端：

• 设置 replication.factor >= 3，确保副本数量。
• 设置 min.insync.replicas >= 2，避免单个副本可用时误判成功。
• 关闭 unclean.leader.election，防止非同步副本被选为 Leader，导致数据丢失。

消费端：

• 关闭自动提交，改为业务处理成功后手动提交位移。
• 确保处理逻辑完成后才提交 offset，避免消息还没处理完就提交，导致进程崩溃后消息被跳过。

面试时用“生产端、Broker 端、消费端”三段式回答，逻辑清晰，面试官也容易继续追问。你还需要补充一句：消息不丢失是整体方案，单独依赖某一端是不够的。

4. 消费者与消费语义

4.1 第 8 问：消费者组与 Rebalance

消费者组是 Kafka 消费端最核心的机制。同一个 Group 下的消费者实例共同消费一个或多个 Topic 的分区，每个分区只会被同组内的一个消费者实例消费。

这里的规则是：分区数决定了组内最多有几个消费者在真正并行消费。如果消费者数量大于分区数，多出来的消费者会空闲。

面试官经常问：消费者数量不够怎么办？那部分分区就没有消费者消费，需要增加消费者实例来分摊分区。

再往下会问 Rebalance。Rebalance 指的是消费者组成员发生变化时，分区被重新分配的过程。触发条件包括：消费者加入/退出消费组、分区数量变化、消费者崩溃。

旧版 Rebalance 存在“全组停止”的问题，即任何一个消费者变动都会触发所有消费者重新加入组，影响消费连续性。新版 Kafka 引入了增量式的协同 Rebalance，以及静态成员等机制来减少影响。

面试答到“Rebalance 会导致消费暂停”这个层面已经不错，如果再能说出“频繁 Rebalance 往往是因为消费者处理耗时太长、会话超时或没有及时拉取消息”，会更加分。

4.2 第 9 问：位移提交：自动提交还是手动提交

位移提交是消费端最容易出问题的地方。

自动提交 enable.auto.commit=true 时，消费者会每隔 auto.commit.interval.ms 自动提交当前拉取到的最大位移。它的缺点是提交时机不可控，可能消息还没处理完就提交了，进程崩溃后这批消息就丢失了；也可能业务处理成功后没有立刻提交，导致重启后重复消费。

手动提交又分为同步提交和异步提交：

• commitSync 会阻塞等待提交结果，可靠性高，但可能影响消费性能。
• commitAsync 不会阻塞，但提交失败时没有重试机制。

实际项目里常见做法是：处理完业务后使用 commitAsync 提交，如果提交失败可以在回调里记录错误，并视情况用 commitSync 做兜底重试。还有一种更精细的方案是按分区提交，或者按消息的批量处理结果提交，取决于业务能否容忍重复消费。

面试时可以强调：手动提交的时机，应该放在业务逻辑成功执行之后，而不是消息拉取之后。

4.3 第 10 问：消息重复消费怎么解决

首先要明确，重复消费在分布式系统里几乎无法完全避免，比如消费端处理完消息后还没来得及提交位移，进程就崩溃了，重启后就会重新消费这一批消息。

所以面试回答的重点是：如何让消费具备幂等性。

常见方案：

• 数据库唯一键约束：消费时往表里插入记录，利用主键或唯一索引避免重复。
• Redis SetNX：在 Redis 里记录消息 ID，处理前判断是否已消费。
• 业务状态判断：比如订单状态已经变成“已支付”，再次收到支付消息时直接忽略。
• 本地消息表：记录已处理消息 ID，配合事务保证幂等。

回答时可以补充：消息系统自带的幂等（生产端幂等性）只能解决生产重复，解决不了消费重复。消费端最终要由业务应用自己来保证幂等。

这会自然引出下一个问题：乱序。

4.4 第 11 问：Kafka 会出现消息乱序吗

Kafka 提供的是“分区内有序”，不是全局有序。同一个分区里的消息，按照写入顺序存储，消费者也会按顺序读取，因此单分区内不会乱序。

如果业务要求全局有序，最直接的办法是让这个 Topic 只有一个分区。但这会牺牲吞吐量，所以实际项目中很少这样做。更好的做法是：根据业务维度划分分区，把需要有序的消息路由到同一个分区。

比如订单消息，可以把订单 ID 作为 Key 发送，这样同一个订单的消息一定进入同一个分区，在这个分区内保持有序。这样既保证了订单维度的消息顺序，又保留了多分区的吞吐能力。

还需要注意一个坑：生产端开启重试后，如果第一条消息发送失败，第二条消息发送成功，第一条消息重试时可能会被追加到后面，导致分区内乱序。解决办法是开启幂等性，它不仅能防止重复，还能让同一分区的消息按序列号严格排序，配合 max.in.flight.requests.per.connection 设置，可靠性更好。

4.5 第 12 问：消息堆积、消费延迟高如何排查

这是线上实战里非常常见的问题，也是面试官非常喜欢深挖的场景。

排查思路可以从消费端、生产端、服务端三层展开：

消费端：

• 检查消费者实例数量是否小于分区数，如果是，增加消费者实例。
• 查看单条消息处理耗时，处理逻辑里是否有慢 SQL、远程调用超时。
• 检查每批拉取的消息条数 max.poll.records 是否设置过大，导致一次处理时间过长。
• 检查消费线程是否被阻塞，比如出现死锁、线程池耗尽。

生产端：

• 检查是否有突发流量，生产速率骤增。
• 检查生产者是否有大量重试，导致消息发送缓慢。

服务端：

• 检查 Broker 的 CPU、内存、磁盘 IO 是否成为瓶颈。
• 检查分区数是否足够，是否存在热点分区导致单分区数据量过大。

排查工具方面，Kafka 消费组命令是常用手段：

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe

执行后可以从 LAG 列看到每个分区当前积压的消息数量。如果某个分区 LAG 特别高，说明消费端在这个分区的处理上存在瓶颈。

答题时能说到“先看 LAG，再看消费者数量和处理耗时，最后检查是否存在热点分区”，就已经是一个完整的排查思路。

5. 性能原理与生产运维

5.1 第 13 问：Kafka 为什么这么快

Kafka 面试题里，“为什么快”是高概率问题，也是区分“用过”和“懂原理”的分水岭。

核心原因有四个：

第一条是顺序写磁盘。Kafka 每条消息都是追加写入分区日志文件，不修改已有数据。顺序写磁盘的性能接近内存写，远高于随机写。

第二条是 Page Cache。Kafka 利用操作系统 Page Cache 缓存最近写入和读取的数据，读写命中缓存时直接操作内存，减少了磁盘 IO。

第三条是零拷贝。消费端读取数据时，数据可以从 Page Cache 直接通过 sendfile 系统调用发送到网卡，不需要在用户态和内核态之间拷贝多次，降低了 CPU 开销。

第四条是批量与压缩。生产端把多条消息攒成一批量发送，消费端批量拉取；批量数据还可以使用压缩算法减少网络传输量。

面试回答时，不要只背名词。可以这样组织：Kafka 把自己定位成文件系统而不是内存缓存，它用顺序追加、页缓存和零拷贝让磁盘和多网络传输的成本大幅下降，同时用分区和批量操作让并行度提升。这三层叠加，才实现了单节点每秒数十万条消息的吞吐能力。

5.2 第 14 问：零拷贝和页缓存到底怎么工作

第 13 问里提到的两个细节，面试官可能会单独追问。

零拷贝是指数据在不需要经过用户空间的情况下，直接从内核空间发送到网络设备。传统的数据传输路径是：磁盘到内核缓冲区，再从内核缓冲区拷贝到用户缓冲区，然后用户缓冲区再拷贝到 Socket 缓冲区，最后发送到网卡。零拷贝通过 sendfile 系统调用，让数据从磁盘或 Page Cache 直接进入网卡，减少两次上下文切换和内存拷贝。

Kafka 在服务端向消费者返回消息时，正好可以用到这个机制。如果数据已经缓存在 Page Cache 里，直接通过 sendfile 发送，CPU 的消耗非常小。

页缓存则是操作系统的文件缓存机制。Kafka 写入消息时，数据先写入 Page Cache，由操作系统在合适时机刷入磁盘。读取消息时，优先从 Page Cache 读取。这种设计让 Kafka 在消息不断读写时，大部分请求都能命中内存缓存。

面试回答时可以说：Kafka 的“持久化”并不会立刻产生磁盘 IO，而是交给操作系统统一调度。它不怕使用 Page Cache 后进程崩溃丢数据，因为 Kafka 本身会通过副本机制保证数据安全。

5.3 第 15 问：Kafka 依赖 ZooKeeper 吗？KRaft 是什么

这是一个比较新的考点，能反映出面试者是否关注 Kafka 版本演进。

早期 Kafka 强依赖 ZooKeeper 来管理集群元数据、Broker 注册、Controller 选举、Topic 配置等。ZooKeeper 的问题在于架构复杂，且 Kafka 集群规模很大时，ZooKeeper 会成为瓶颈。

从 Kafka 3.x 开始，社区引入 KRaft 模式，也就是用 Kafka 自身来存储元数据，逐步替代 ZooKeeper。KRaft 模式下，Kafka Controller 通过 Raft 协议选举，不再需要额外部署 ZooKeeper。Kafka 4.0 之后移除了 ZooKeeper 支持。

面试回答时，不要面面俱到，重点说清楚：

• 旧版本用 ZooKeeper。
• KRaft 是新的元数据管理方式，目的就是去 ZooKeeper。
• 生产升级时要关注版本对应关系，确认目标是 3.x 或 4.x，再决定升级路径。

5.4 第 16 问：集群宕机、单机升级和集群升级怎么处理

这一问属于生产运维经验题，没有实操过的人容易答得虚。

先聊集群宕机。首先要判断宕机范围。单台 Broker 宕机时，如果副本数配置合理（比如 3 副本），分区 Leader 会切换到其他副本，集群整体可用，影响是短暂延迟。如果是整个集群宕机，说明是多节点同时不可用或者网络分区，恢复优先级是：先恢复元数据，再恢复 Broker 服务，最后确认消息是否完好。

处理时要强调：不要盲目重启，先看日志。宕机原因可能是磁盘写满、内存溢出、网络分区、版本 Bug 等。不同原因恢复方式不同。

单机版本升级和集群版本升级的核心原则是：

• 先备份配置和数据。
• 在测试环境完整验证一遍。
• 生产升级前查看版本兼容性说明。
• 采用滚动升级方式，逐台升级 Broker，保证集群在升级过程中对外可用。
• 如果跨大版本，比如从 2.x 升到 3.x，要关注 ZooKeeper 到 KRaft 的变化，不要盲目操作。

升级命令本身没有太多可说的，关键是升级顺序：先升级 Server 端，再升级客户端。如果消费者或生产者客户端版本太旧，可能无法兼容新 Broker，升级后会报异常。

6. 面试追问应对与高频踩坑

6.1 常见的连环追问

面试官不会只问一道题的答案，他会在你回答过程中抓细节继续问。比如：

• 你刚说 acks=all，那 min.insync.replicas 设置多大合适？
• 你说开启幂等性，幂等性原理是什么？
• 你提到手动提交，手动提交有哪些注意事项？
• 你说分区内有序，那生产端重试会导致乱序吗？
• 消费堆积你遇到过吗？最后怎么解决的？

这些问题都来自同一个知识链路。如果你在准备时能沿着“消息生命周期”把每个环节串起来，连环追问其实并不可怕。怕的是只背了结论，不知道结论背后的机制。

6.2 一条命令引发的追问：消费指定时间

有些面试官会从使用细节切入，比如：Kafka 消费命令怎么指定消费时间？

不同版本支持方式略有差异，比较常用的是通过 Kafka Tools 或消费组 API 重置位移来实现。也可以使用 Kafka 自带的命令行工具。例如在新版本中，kafka-consumer-groups.sh 支持重置位移：

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group \ --topic test-topic --to-datetime 2025-01-01T00:00:00.000 \ --execute

注意：这类命令在不同版本中参数名称可能不同，生产环境使用前一定要在测试环境验证，且要明确对消费组位移的影响，避免影响线上数据消费。

如果只是想临时查看某个时间点之后的消息，可以使用控制台消费者：

kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic test-topic --partition 0 --offset 100

这种用法指定的是绝对偏移量。真正的“按时间消费”通常要配合分区时间索引来实现，不同版本支持不一样。回答时建议说明思路，不要把某个版本的具体命令说得过于绝对。

6.3 现场写代码可能会被问什么

除了理论和命令，Kafka 面试还可能出现简单的编码题。最常见的是写一个消费者，要求手动提交位移，并且保证业务处理完成后再提交。

下面是一个可复现的 Java 消费者示例：

// 文件路径：src/main/java/com/example/kafka/ConsumerSample.java Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("group.id", "my-group"); props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); // 关闭自动提交，改为手动提交 props.put("enable.auto.commit", "false"); KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Arrays.asList("test-topic")); try { while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); for (ConsumerRecord<String, String> record : records) { // 1. 先处理业务 System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value()); // 2. 幂等处理，例如记录消息ID到本地表或Redis } // 3. 业务处理完成后再提交 consumer.commitAsync(); } } finally { consumer.close(); }

这个示例虽然简单，但能体现出：你知道要关自动提交，知道要处理完再提交，知道异步提交可能失败。面试官如果追问“异步提交失败怎么办”，你可以回答：在回调里记录失败日志，并通过 commitSync 做最终兜底，或者把失败位移信息发送到监控系统。

7. 复习路线与实际建议

7.1 三天怎么安排

如果你想在短时间内掌握这 16 问，可以按三天计划推进：

• 第一天：先通读概念和原理类问题，比如分区副本、ISR、HW、生产流程。目标是能画出 Kafka 消息从生产到消费的整体链路。
• 第二天：搭一个本地 Kafka 环境，亲手执行主题创建、消息发送、消费、查看 LAG、重置消费位移等操作。目标是让命令与实际概念对上号。
• 第三天：做输出练习。把 16 个问题写在纸上，不看资料，用自己的话讲一遍。讲不清楚的地方，就是需要重新复习的盲点。

这个节奏不要求你面面俱到，而是用“理解 + 验证 + 复述”的方式，把面试最常见的知识真正内化。

7.2 易错点清单

• 把 HW 和 LEO 混为一谈。HW 是已提交位移，LEO 是日志末端位置。
• 认为开启幂等性就不会重复消费。幂等性解决的是生产端重复，消费端重复需要业务幂等兜底。
• 认为 acks=all 就绝对不丢消息。还要看 min.insync.replicas 配置。
• 认为 Rebalance 是坏事。无损的 Rebalance 是正常机制，怕的是频繁触发。
• 升级 Kafka 时只注意服务端，忽略客户端版本兼容性。
• 手动提交时把 commitSync 放到业务处理之前，这是很典型的错误。
• 消息堆积时只想到加消费者。如果消费者数量已经等于分区数，加实例没有用，需要增加分区或优化单条消息处理速度。

7.3 复习的落脚点

Kafka 面试题再多，核心其实是一条链路、两个端、三组机制。一条链路是消息从生产到消费的完整路径；两个端是生产端和消费端；三组机制是可靠性机制、顺序性机制和性能机制。把这三条线吃透，16 问也好，连环追问也罢，你都能从容应对。

建议你从今天开始，先动手找一个你能控制的 Kafka 环境，哪怕是单机版，把生产消费、位移提交、消息堆积这几个场景实际跑一遍。代码跑通之后，再回到这 16 个问题逐题做复述练习。到面试时，你心里装的就不再是零散的答案，而是一套可以随时调用的完整知识网。