Kafka 面试题（2026-06-18）
【面试题】1. 消费组协议里的 Generation 和 Member ID 分别是什么？Kafka 怎么用它们防止"僵尸消费者"？
【标准答案】Member ID 是消费者加入消费组时 Coordinator 分配的唯一标识，重启后换新的。Generation 是消费组的"代际版本号"，每次消费组发生 Rebalance 就 +1，组内所有消费者持同一个 Generation。这两个参数配合起来就是为了干掉"僵尸消费者"：一个消费者之前持有 Generation=5，因为 GC 暂停了 60 秒没发心跳，Coordinator 把它踢了触发 Rebalance 升到 Generation=6，这个消费者醒来后拿 Generation=5 尝试提交位移——Coordinator 一看 generation 过期了，直接甩 ILLEGAL_GENERATION 异常拒绝。还有更狠的 fencing 机制：如果那个僵尸不死心还想去旧分区拉消息，Leader 发现它的 Member ID 和当前分配给该分区的消费者对不上，直接拒绝服务。这样就保证了一个消费者被踢出组后没法再对旧分区指手画脚。Kafka 2.4+ 还加了 group.instance.id 功能，静态成员模式下消费者重启后能保持相同的 Member ID，避免误判触发的 Rebalance。
【面试题】2. Kafka 日志压缩（Log Compaction）的底层 Cleaner 线程是怎么工作的？为什么它删不干净"同一个 Key 只留最后一条"？
【标准答案】Log Compaction 不是实时删，是后台异步渐进式搞的。Cleaner 线程分三步走：第一步——选"最脏"的 Segment（已提交消费位移位置之前、且脏数据比率最高的段），脏比率 = 可清理字节 / 总字节；第二步——把选中的 Segment 读进内存，建一个哈希表，Key 到最新 offset 的映射；第三步——遍历 Segment，哈希表说这个 offset 不是该 Key 的最新值，删；是，保留。然后把保留的消息重写到新 Segment 文件，旧文件直接删。但"删不干净"的原因是：一、Cleaner 只扫描已提交位移之前的 Segment（消费者还没消费到的不动，不能影响在线消费）；二、脏比率阈值由 min.cleanable.dirty.ratio 控制（默认 0.5），不够脏就不扫，所以同一个 Key 可能短期内在多个 Segment 都有值；三、活跃 Segment（当前正在写的 .log 文件）Cleaner 完全不碰。所以"最终只有每个 Key 的最新值"是真的，但"立刻就能看到"是假的——取决于清理速度和你设置的清理阈值。
【面试题】3. 消费者拉消息的参数太多容易搞混——fetch.min.bytes、fetch.max.wait.ms、fetch.max.bytes、max.partition.fetch.bytes 分别管什么？怎么配合？
【标准答案】这四个参数控制"一次 poll() 拉多少数据"的两个阶段。第一阶段——攒数据：fetch.min.bytes 和 fetch.max.wait.ms 是一对，告诉 Broker "数据不够这么多就等着，但最多等这么久"。比如 fetch.min.bytes=1MB、fetch.max.wait.ms=500ms，意思是 Broker 在 500ms 内攒够 1MB 就返回，攒不够 500ms 到了也返回现有数据。这两个参数配合是为了减少空拉取和网络往返，低延迟场景把 min.bytes 调小、实时但允许稍高延迟的批处理场景调大。第二阶段——限上限：fetch.max.bytes 是单次 poll() 返回的总上限，max.partition.fetch.bytes 是单个分区拉取的上限。如果 Topic 有 10 个分区且都有数据，单分区限 1MB、总上限 50MB，一次能拉 10MB。如果 fetch.max.bytes 设太小（比如 50MB），但 max.partition.fetch.bytes 设大（比如 10MB），有 8 个分区有数据时跑不完所有分区就碰总上限了，剩下的分区下次轮才拉。坑：max.partition.fetch.bytes 必须大于单条消息的最大大小，否则消费者拿到不完整的消息直接崩。
【面试题】4. 都说 acks=all 不会丢消息，但什么极端场景下 acks=all 也丢？你还得加什么配置才真正做到"零丢失"？
【标准答案】acks=all 的承诺是"所有 ISR 副本写完了才返回"，但如果 ISR 里只有一个副本（Leader 自己），acks=all 退化成了 acks=1——Leader 写成功就返回，万一这台 Broker 宕机且磁盘损坏，数据就丢了。所以必须要 min.insync.replicas ≥ 2（至少一个 Follower 确认），假如 replication.factor=3，min.insync.replicas=2，意味着 Leader + 至少一个 Follower 写完才算完。还有一个坑：unclean.leader.election.enable=true ——允许非 ISR 里的副本当选 Leader，比如 ISR 全挂了只剩一个落后副本，它被选为新 Leader，落后的那条数据就丢了。必须把这个设成 false，宁可不可用也绝不丢数据。第三个坑：生产者端 delivery.timeout.ms 设太短，重试没跑完就报超时，消息实际没落盘但业务以为已经丢了。完整"零丢失"配置清单：acks=all + min.insync.replicas=2（且 < replication.factor）+ unclean.leader.election.enable=false + enable.idempotence=true + retries=MAX_INT + delivery.timeout.ms 足够大。
【面试题】5. Kafka Broker 的 ReplicaFetcher 线程是怎么从 Leader 同步数据的？Follower 的 fetch 流程和消费者有什么不同？
【标准答案】ReplicaFetcher 是每个 Follower Broker 的后台线程，专门负责从 Leader 拉副本数据。流程：Follower 向 Leader 发 Fetch 请求，带上自己的 LEO——Leader 从本地日志读到从该 LEO 开始的一段数据，把数据和自己的 HW 一起返回。Follower 收到后：一、把消息追加到本地日志并更新 LEO；二、用 Leader 返回的 HW 更新自己的 HW；三、把新 LEO 上报给 Leader（通过下一次 Fetch 请求的 header）。跟消费者的区别：一、消费者拉取有 HW 限制（只能读到 HW 之前的数据），ReplicaFetcher 没有这个限制，它直接从 Leader 的 LEO 位置读；二、ReplicaFetcher 不跳过压缩，原样搬二进制日志，消费者要解压；三、ReplicaFetcher 不受消费组协调器管理，它自己的位置就是分区日志的末尾，永远追着最新数据跑。ReplicaFetcher 的数量由 num.replica.fetchers 控制（默认 1），分区分到不同 Broker 时可以考虑调大提高副本同步吞吐。
【面试题】6. Kafka 消费者位移提交是"批量"的，RabbitMQ 是单条 ACK——这导致了两者在使用模式上的根本区别是什么？
【标准答案】RabbitMQ 是单条消息手动 ACK——消费一条确认一条，确认了 Broker 立刻删消息。搞的是"任务处理"，每条消息是独立的不可变任务，精确保一次（at-most-once 或 at-least-once）。Kafka 提交的是位移——一个游标告诉 Broker"这个 offset 之前的我全处理完了"，本质是"日志消费"，关注的是流的连续性而非单条确认。这个底层差异导致：RabbitMQ 可以轻松搞定"这条消息我处理不了，NACK 退回队列重试"，Kafka 不行——你没法把这条消息插回到原来的 offset 位置让它重来，Kafka 消费者只能 seek() 回退到之前的 offset 整批复消费。所以 Kafka 的处理模式是"幂等消费"——每条消息的处理逻辑必须支持重复执行不重复生效；如果需要单条 NACK 级别的细粒度控制，你得自己搞个死信 Topic 把处理失败的消息转发过去。一句话：RabbitMQ 的消息模型是"投递—确认—删除"，Kafka 是"追加—消费—移动游标"，基因不同决定了场景不同。
【面试题】7. Kafka 3.x 从 ZK 迁移到 KRaft 的详细步骤？有哪些雷不能踩？
【标准答案】迁移不是原地升级，是建新集群倒数据，因为 ZK 和 KRaft 是两个不互通的元数据管理模型。标准迁移路径：第一步，部署一个全新的 KRaft 集群，3 个 Controller 节点起步，Broker 数跟老集群对齐。第二步，用 MirrorMaker 2 把老集群所有 Topic 的数据同步到新集群——MM2 支持 offset sync，消费者的位移也能一并迁移过去。第三步，验证新集群的数据一致性和消费水位。第四步，修改生产者和消费者的连接地址指向新集群，分批灰度切流——先切 10% 流量观察 30 分钟没问题再全切。第五步，老集群保留一段时间做回滚后手，确认没问题后下线。不能踩的雷：一、KRaft 模式下 Controller 节点和 Broker 节点要分开部署——Controller 不能扛数据流量，否则 Raft 共识被业务读写干扰；二、metadata.version 升级是不可逆的，一旦升级到 KRaft 专用的 metadata.version 就不能降回 ZK 模式；三、Security（ACL/SASL）配置在 KRaft 下的存储位置变了，要从 ZK 的 /kafka-acl 路径迁移到 @metadata Topic 里，别漏；四、KRaft 用 controller.quorum.voters 配置 Controller 节点列表，格式是 id@host:port，端口别写错——写错集群起不来。
【面试题】8. 线上 Leader 分区频繁切换（Leader 抖动），每秒几十个分区在换 Leader，监控面板一片红，怎么排查？
【标准答案】Leader 频繁切换的本质是 Controller 不断收到"某些 Broker 不可用/重新可用"的信号，频繁执行 Leader 选举。排查按频率从高到低排查三条线：第一条线——网络层：看 Broker 之间的网络延迟和丢包率。如果 A 和 B 之间的网络间歇丢包，B 上的 Follower 连接不到 A 上的 Leader，Controller 就切 Leader 到 C。过一会儿网络恢复，Controller 看原来的 Leader 回来了可能又切回去。用 iperf 或 tcpping 测 Broker 间的网络稳定性。第二条线——GC 停顿：看 Broker 的 GC 日志是否有频繁 Full GC。一次 10 秒的 STW 就足以让 Broker 的 ZK session 超时，告 Controller 它下线了。ZK session 超时的瞬间该 Broker 上所有 Leader 分区的领导权被切走，GC 恢复后又抢回来。第三条线——磁盘 IO 打满：用 iostat 看磁盘 await 和 util%。如果 Follower 所在 Broker 磁盘 IO 飙到 100%，ReplicaFetcher 同步变慢，超过 replica.lag.time.max.ms 被踢出 ISR，Leader 数量随之变化。解决：短期调大 zookeeper.session.timeout.ms 到 20s+ 避免 GC 误判，调大 replica.lag.time.max.ms 到 60s 给 IO 缓冲。长期：隔离 Broker 间网络到同一交换机、优化 GC 参数、磁盘换 SSD 或上 JBOD 分散 IO。
【面试题】9. 你要为一个中型团队设计 Kafka 多租户隔离方案，既要防止租户互相干扰，又要运维成本可控——怎么分层设计？
【标准答案】多租户隔离不是非黑即白，分三层渐进式做。第一层——逻辑隔离（Quota + ACL）：这是最小成本方案，所有租户共享同一集群。给每个租户分配唯一的 client.id 前缀，用 kafka-configs.sh 设 producer_byte_rate 和 consumer_byte_rate 配额，防止某个租户的批量任务把集群带宽吃光。ACL 用 kafka-acls.sh 给每个租户只授权自己的 Topic 前缀读写，设最小权限原则。第二层——物理部分隔离（Broker 级隔离）：把重要租户的 Topic 通过分区重分配到特定 Broker 上，不跟其他租户混盘。用 Cruise Control 做自动化负载均衡时加规则约束。不同租户的数据在不同 Broker 上，磁盘 IO 和网络互相不干扰。第三层——完整物理隔离（给钱多的大租户）：单独部署一套小集群，物理隔离不跟任何人共享。自己配 Quota 和 ACL。这三层不是互斥的——可以用第一层覆盖 80% 的租户，第二层给核心业务，第三层给 VIP。运维成本递增，从"一套集群 + 自动化管理"到"N 套集群 + 每套独立运维"，根据自己的团队规模选择。核心经验：Quota 和 ACL 必须上，不需要完整物理隔离的问题别自己加复杂。
【面试题】10. 如果让你用 Kafka 实现一个"订单超时自动取消"的延迟消息功能，你会怎么设计？Kafka 本身没有死信和延迟队列，怎么绕？
【标准答案】Kafka 没有内置延迟消息，但有几个方案能实现。方案一：多级延时 Topic——建 delay_1m、delay_5m、delay_30m、delay_1h 等不同延迟等级的 Topic，订单消息先发到对应 delay Topic，消费者开启后先 sleep 对应的延迟时间再消费。延迟低还好，延迟高（比如 30 分钟后）消费者长时间 pause 不 poll 会触发 max.poll.interval.ms 超时被踢出组——解决方法是把 sleep 放 poll 外部，poll 频率保持正常，处理逻辑里判断当前时间是否到了才执行。方案二：时间轮 + 数据库持久化——生产者把延迟消息写到数据库，带上期望执行时间，后台用时间轮定时扫描到期任务投递到实际消费 Topic。方案三（推荐）：直接用 RocketMQ——它的延迟消息是原生支持的，设 delayLevel 就行，18 个等级从 1s 到 2h，开箱即用。如果团队要在 Kafka 上强搞，大部分最后都后悔了——Kafka 的设计假设是顺序追加日志流转，现在要用它做"暂停—唤醒"逻辑等于逆着用，性能和可靠性都不好。延迟消息就用 RocketMQ，业务消息走 Kafka，各司其职。
生成时间：2026-06-18 23:08 覆盖考点：消费组协议(Generation/Member ID)、日志压缩底层(Cleaner线程)、消费者拉取参数(fetch参数协同)、acks=all极端丢消息场景、ReplicaFetcher线程同步机制、Kafka位移提交 vs RabbitMQ ACK对比、ZK迁移KRaft迁移流程、Leader抖动排查、多租户隔离方案、延迟消息实现方案