Kafka 面试题（2026-06-18）
【面试题】1. 说一下 Kafka 的整体架构，几个核心角色分别干什么？
【标准答案】Kafka 架构就四个角色：Producer（生产者）往 Broker 发消息；Broker 是服务端节点，负责存消息、响应读写请求；Consumer（消费者）从 Broker 拉消息消费；ZooKeeper/KRaft 负责集群元数据管理和控制器选举。消息在 Broker 里按 Topic 分类，每个 Topic 又分成多个 Partition 做并行和水平扩展。每个 Partition 有多个副本，一个 Leader 负责读写，Follower 从 Leader 同步数据。消费者组是 Kafka 的消费模型核心，组内多个消费者共享消费某个 Topic，同一分区只能被组内一个消费者消费，这样保证了消费的有序和负载均衡。整体思路就是：分区解决并行，副本解决高可用，消费组解决水平扩展。
【面试题】2. Kafka 生产者的 acks 参数有哪几个值，分别代表什么？
【标准答案】acks 控制生产者对消息"发送成功"的定义，有三个值。acks=0：生产者发完就走，不等 Broker 任何确认，最快但可能丢消息，适合日志采集这种丢了无所谓的数据。acks=1：Leader 收到消息并写入本地日志就返回成功，不用等 Follower 同步，如果 Leader 在 Follower 同步前挂了，消息就丢了。这是生产环境最常用的配置，兼顾了性能和可靠性。acks=all 或 -1：Leader 必须等所有 ISR 里的副本都同步完成才返回成功，最强可靠性保障，配合 min.insync.replicas 使用更稳——比如设置 min.insync.replicas=2，至少两个副本确认，哪怕 Leader 挂了也能保证数据不丢。代价就是延迟高、吞吐低。
【面试题】3. Kafka 的消费者组是什么？组内多个消费者怎么分工的？
【标准答案】消费者组是一组消费者实例的集合，它们共享同一个 group.id，协同消费一个或多个 Topic。核心规则很简单：一个 Partition 在同一时刻只能被组内的一个消费者消费，但一个消费者可以同时消费多个 Partition。如果组内消费者数量大于 Topic 分区数，会有消费者空转吃白饭。分工机制是：组内消费者通过 Rebalance 来分配分区，Coordinator 选出一个 Group Leader 消费者，由它根据分区分配策略（Range、RoundRobin 等）算出分配方案，上报给 Coordinator 执行。这个机制的好处是能水平扩展——消费不过来了加消费者就行，消费者挂了组内自动重分配，消费不断流。
【面试题】4. ISR 是什么？什么情况下副本会被踢出 ISR？
【标准答案】ISR（In-Sync Replicas）是和 Leader 保持同步的副本集合，是 Kafka 高可用的核心机制。一个副本要留在 ISR 里，必须满足 replica.lag.time.max.ms（默认 30 秒）内持续跟上 Leader 的同步进度。如果 Follower 超过这个时间没同步或者落后太多，就会被从 ISR 里踢出去。踢出后 Kafka 只依赖 ISR 里的副本做确认（acks=all 时），被踢出的副本会自己追赶，追上后再重新加入 ISR。有个坑要注意：ISR 缩容到只剩 Leader 时，acks=all 实际退化成 acks=1，风险很大。所以线上最好设置 min.insync.replicas ≥ 2，保证 ISR 里至少有 2 个副本才能写入，避免单点故障。
【面试题】5. Kafka 的消息是怎么存在磁盘上的？日志分段又是什么？
【标准答案】Kafka 的消息以日志（Log）形式顺序追加写入磁盘，每个 Partition 在磁盘上就是一个目录，目录内有多个日志分段文件（LogSegment）。分段文件由三部分组成：.log 存消息体，.index 存偏移量索引做快速定位，.timeindex 存时间索引支持按时间找消息。分段大小由 log.segment.bytes 控制（默认 1G），满了就滚动切新文件。Kafka 的清理策略有两个：按时间或大小删除旧分段（delete），或者用 Compact 策略只保留每个 Key 最新值的消息。分段设计的好处很明显：读写都集中在新分段上，老分段很少动，磁盘顺序读写性能极高；清理直接删文件，不用逐条删，效率也高。
【面试题】6. 自动提交位移和手动提交位移有什么区别？什么场景用哪种？
【标准答案】自动提交（enable.auto.commit=true）：Kafka 消费者按 auto.commit.interval.ms（默认 5 秒）定时自动提交位移，最简单省心，但问题也很明显——可能还没处理完消息就提交了，消费者挂了就会丢消息；也可能处理完了还没到定时提交点就挂了，重启后重复消费。手动提交：关了自动提交后自己调 commitSync()（同步）或 commitAsync()（异步）提交位移，控制粒度更细，可以在业务处理完后再提交，实现"至少一次消费"语义。生产环境建议：一般业务用自动提交+处理好幂等就行；涉及钱、订单等强一致性场景必须手动提交，在业务落库后再 commit，配合幂等性设计保证不丢不重。
【面试题】7. Kafka 的三种分区分配策略 Range、RoundRobin、Sticky 各有什么优缺点？
【标准答案】Range（默认）：按 Topic 逐个做分区分配，分区编号连续的分给同一个消费者。优点是简单直观，缺点是容易数据倾斜——如果 Topic 多、消费者数量不是分区数的整除时，前面的消费者会多分到分区。RoundRobin：把所有 Topic 的分区打散后排成一排轮流分配，分配更均匀。但它在 Rebalance 时会重新打散全部分区，之前消费者持有的分区可能全换掉，对有状态消费不友好。Sticky（推荐）：兼顾均匀分配和 Rebalance 时的最小扰动。第一次分配尽量均匀，后续 Rebalance 只移动最少量的分区，大部分分区保持不动。这样减少了 Rebalance 的迁移成本和中断时间，配合 Cooperative Sticky（增量重平衡）效果更佳，线上尽量用这个。
【面试题】8. 线上 Kafka 消息积压几十万条，你怎么排查和处理？
【标准答案】消息积压排查分四步走。第一步看监控：确认是哪个 Topic、哪个消费组积压，积压量和增速多少。第二步定位瓶颈点：是消费者处理慢（CPU 打满、DB 慢查询、下游依赖超时），还是消费者数量不够分区多导致处理不过来，还是 Broker 端网络/磁盘 IO 瓶颈。第三步止损：紧急的话临时加消费者实例扩容消费能力；如果是消费逻辑慢，可以临时上线一个"转移消费者"把消息快速消费到另一个 Topic 或磁盘暂存，再慢慢消化。第四步根治：消费慢就优化代码（批处理、异步化、缓存）、开并发消费（多线程处理一个分区要注意顺序性）；消费者少就加实例，但加了不能超过分区数。另外检查下是不是 Rebalance 频繁导致的——consumer 处理时间太长导致心跳超时，反复触发 Rebalance 会让消费能力雪崩式下降，调大 max.poll.interval.ms 和 session.timeout.ms 就行。
【面试题】9. 你们的 Kafka 项目里，怎么保证消息不丢和不重复消费？
【标准答案】保证不丢消息要从生产者、Broker、消费者三个环节堵死。生产者端：acks=all + min.insync.replicas=2 + 发送失败重试（retries=MAX）+ 开启幂等（enable.idempotence=true），保证发出去的消息至少写一次且不重复。Broker 端：replication.factor ≥ 3，unclean.leader.election.enable=false，不允许 ISR 外的副本选为 Leader，防止落后副本上位丢数据。消费者端：业务处理完再手动提交位移，不要读完马上提交。
防重复消费的核心是做幂等。因为"至少一次"语义下重试、Rebalance 都会导致重复消息。办法是用消息里的业务唯一 ID（订单号、流水号）做去重键，消费时先查 Redis/DB 看有没有处理过，处理过就跳过。事务型消息可以用 Kafka 事务 + 幂等生产者做到"恰好一次"语义，但代价大，一般业务做个幂等+ack=all 就够用了。
【面试题】10. Kafka、RocketMQ、RabbitMQ 选型怎么考虑？你的项目为什么选 Kafka？
【标准答案】三个 MQ 的定位不同，选型看场景。RabbitMQ：Erlang 写的，延迟低（微秒级），功能丰富，路由规则灵活，适合业务系统间的异步解耦、RPC 调用，运维简单。但吞吐量是硬伤，单机万级 TPS，横向扩展能力弱，高吞吐场景扛不住。RocketMQ：阿里出品，Java 生态友好，支持事务消息、延迟消息、消息过滤等业务特性丰富，单机十万级 TPS，适合电商、金融这类需要复杂消息特性的业务场景。Kafka：主打超高吞吐和海量数据流式处理，单机百万级 TPS，顺序写磁盘+零拷贝玩到极致，生态强（Flink/Spark/KSQL 全家桶），但功能相对单一，没有延迟消息、死信队列需要自己实现。
选型原则：公司业务以大数据、日志、流计算为核心的选 Kafka；以复杂业务消息、分布式事务为核心的选 RocketMQ；传统企业系统、对低延迟有要求的选 RabbitMQ。我们项目是实时日志采集+数据处理链路，几十万 TPS，所以选 Kafka。