Kafka 面试题（2026-06-18）
【面试题】1. 生产者发送消息时，怎么决定消息落到哪个分区？
【标准答案】Kafka 生产者有三种分区路由策略。第一，消息指定了 Key：对 Key 做 hash 后再对分区数取模，相同 Key 的消息一定进同一分区，保证局部有序。分区数变动会破坏这个规则，所以线上尽量不轻易改分区数。第二，消息没指定 Key：Kafka 2.4 前用轮询，2.4 后默认用"粘性分区"（Sticky Partitioning）——一批消息先粘在同一个分区发送，满了再换下一个，比轮询批处理效率更高、延迟更低。第三，自定义分区器：实现 Partitioner 接口，按业务规则指定分区，比如按用户 ID、地区做路由。面试官爱追问：如果想让某个 VIP 用户的消息优先处理怎么办？答案就是自定义分区器把 VIP 消息路由到专属分区，然后消费者那边优先消费那个分区。
【面试题】2. Kafka 的控制器（Controller）是干什么的？挂了会发生什么？
【标准答案】Kafka 集群里有一个特殊的 Broker 叫 Controller，它是集群的大脑，核心职责有五个：一、监听 Broker 上下线，当 Broker 挂了负责重新分配 Leader；二、管理 Topic 的创建、删除和分区扩容；三、选举分区 Leader，维护 ISR 成员变更；四、向所有 Broker 同步集群元数据；五、触发分区重分配和副本迁移。Controller 挂了会自动重选——ZooKeeper/KRaft 模式下，所有 Broker 抢着注册临时节点，先到先得。选举期间集群短时间内无法做元数据变更，但不影响已有分区的正常读写，因为读写走的是分区 Leader，不依赖 Controller。新 Controller 选出来后从 ZK/元数据日志恢复全局状态继续干活。重点是 Controller 的负载要轻，大的分区重分配别频繁搞，不然 Controller 压力大会拖垮整个集群。
【面试题】3. 什么是 Kafka 的拦截器？生产者和消费者拦截器分别能干什么？
【标准答案】拦截器（Interceptor）是 Kafka 客户端的一个扩展点，在消息发送前或消费前后插一段自定义逻辑，不侵入业务代码。生产者拦截器有两个钩子：onSend() 在消息序列化后、分区分配前触发，典型用法是给消息统一加时间戳、加 TraceId 做全链路追踪、做消息审计日志；onAcknowledgement() 在收到 Broker 确认后触发，可以做发送成功率统计、异常告警。消费者拦截器也有两个：onConsume() 在 poll 拿到消息后、业务处理前触发，可以用来做消费延迟计算（消息时间戳减当前时间）、消息去重过滤；onCommit() 在提交位移后触发，可以做消费进度监控。拦截器之间是链式调用，按配置顺序执行，一个挂了不阻断后续但会抛异常，生产上别在拦截器里搞重逻辑，保持轻量。
【面试题】4. Kafka Consumer Rebalance 的触发条件有哪些？怎么减少不必要的 Rebalance？
【标准答案】Rebalance 触发条件有三类：第一，消费者组成员变更——有新消费者加入或已有消费者宕机/主动离组；第二，订阅的 Topic 分区数变化——动态扩容了分区；第三，消费者处理消息太慢，超出 max.poll.interval.ms（默认 5 分钟），被 Coordinator 踢出组再重新加入。
减少 Rebalance 的四个优化点：一、加大 max.poll.interval.ms，给足消费者处理时间；二、合理设置 session.timeout.ms 和 heartbeat.interval.ms，心跳不要太频繁但也不能太长，建议 heartbeat 是 session 的 1/3；三、用 Cooperative Sticky 策略做增量 Rebalance（Kafka 2.4+），只重分配变化的分区而不是全量打散，大幅降低中断时间；四、不要在消费回调里跑耗时逻辑，poll 拿到消息后异步批量处理。核心思路就是：让消费者别超时被踢，让 Rebalance 发生时影响面最小。
【面试题】5. Kafka 怎么保证消息的顺序性？有哪些场景会破坏顺序？
【标准答案】Kafka 只保证同一分区内的消息严格有序，不同分区之间无序。所以要保证顺序，核心做法是：把需要有序的消息用同一个 Key 发送，保证它们落到同一个分区。消费者端单线程消费一个分区也能保证消费顺序。
三个破坏顺序的坑：第一，生产者设置 retries > 0 且没开启幂等（max.in.flight.requests.per.connection > 1），消息 A 发送失败重试时消息 B 已发送成功，导致 B 在 A 前面——解决是开启幂等把 max.in.flight 设成 5 也不会乱序。第二，消费者多线程并行消费同一个分区，处理完的顺序和消息到达顺序不一致——解决是分区内单线程消费，如果慢就改方案：一个线程拉消息，按 Key 哈希分发给多个内存队列，每个队列单线程处理。第三，Rebalance 时分区被转移，新消费者从上次位移继续，但如果之前消费者还有未处理完的消息就可能乱。设计上尽量让顺序性强的 Topic 分区数固定不轻易改。
【面试题】6. Kafka 的事务是怎么实现的？什么场景真正需要用到事务？
【标准答案】Kafka 事务是"恰好一次"语义的核心，解决的是"读-处理-写"跨分区跨 Topic 的原子写问题。实现主要靠两个组件：事务协调器（Transaction Coordinator）和事务日志（__transaction_state 内部 Topic）。流程是：生产者初始化事务时向 Coordinator 申请事务 ID，拿到 PID；每次发消息带事务标记；提交时走两阶段——先 PREPARE，所有涉及分区标记 Prepare 状态，再 COMMIT，写入事务提交标记。消费者端配合 read_committed 隔离级别，只读到已提交的事务消息，过滤掉未提交和已中止的消息。
真正需要事务的场景不多：典型的是流处理中"消费一条消息→处理后→产生多条输出消息到不同 Topic"需要原子写入，比如订单状态流转同时更新订单 Topic 和分析 Topic。大多数业务场景 acks=all + 幂等生产者 + 业务幂等就够用，事务代价大（延迟+50%、吞吐下降），别为了用而用。
【面试题】7. Kafka 零拷贝（Zero-Copy）是什么原理？它怎么做到高性能的？
【标准答案】零拷贝是 Kafka 高吞吐的关键技术之一。传统数据传输：磁盘→内核 Read Buffer→用户空间 Buffer→内核 Socket Buffer→网卡，四次拷贝、四次上下文切换，又慢又吃 CPU。零拷贝（sendfile 系统调用）：磁盘→内核 Read Buffer→直接通过 DMA 引擎拷贝到网卡，跳过了用户空间，只两次拷贝、两次切换。对应的 Java 实现是 FileChannel.transferTo()，Kafka 在消费者端大量使用——Broker 读取日志文件直接通过零拷贝发到网络 Socket，不经过应用层。
除此之外 Kafka 还有两个提速手段：一是顺序写磁盘，比随机写快三到四个数量级，利用了磁盘线性写入的物理特性；二是 PageCache，读操作优先走 OS 的页缓存，热点数据全在内存里，命中率高。三者叠加：顺序写+PageCache+零拷贝，就是 Kafka 单机百万 TPS 的底层密码。
【面试题】8. 线上 Kafka Broker 频繁 Full GC 导致读写超时，你怎么排查和优化？
【标准答案】Broker Full GC 排查分四步。第一步看 GC 日志和监控，确认是 Young GC 频繁还是 Full GC，Full GC 频率和耗时多少，是不是达到了影响请求处理的程度。第二步查内存大头：通常三块——PageCache 被日志读写大量消耗不是问题（这是 OS 内存不算堆），真正堆内内存问题出在：一、每连接网络线程创建了大缓冲区；二、Topic 和分区元数据太多导致 Metadata 缓存过大；三、大量网络连接和请求队列占用。
优化方向：堆内存控制在 6G 以内（Kafka 依赖 PageCache，堆不要太大），用 G1GC 替代 CMS（减少碎片），调大 socket.send.buffer.bytes 和 socket.receive.buffer.bytes 直接用堆外内存；压缩类型从 gzip 换成 lz4 或 snappy——CPU 开销低、压缩比与速度平衡；如果分区数过多（单 Broker 超过几千个分区），考虑合并分区或拆分集群，分区元数据吃内存很厉害，极端情况一个分区开关都可能拖死 Broker。
【面试题】9. Kafka 的高可用架构怎么设计？多机房容灾怎么做？
【标准答案】单集群高可用三板斧：一、多 Broker 部署（至少 3 个），避免单点故障；二、Topic 的 replication.factor ≥ 3，分区 Leader 挂了自动切换；三、min.insync.replicas ≥ 2，确保写入时有冗余确认。配合机架感知（broker.rack）把副本分散到不同物理机架，防止交换机故障导致整个机架副本全挂。
多机房容灾常用方案是 MirrorMaker 2（MM2）：在主备两个集群之间同步消息，核心优势是基于 Kafka Connect 框架，支持自动主题发现、位移同步、防止循环复制。关键配置：合理设置 replication.policy.class 处理偏移翻译，emit.heartbeats.enabled 做心跳监控。还有两种方案：一是客户端双写，业务直接写两个集群，延迟最低但侵入性强；二是基于存储层的异步容灾，但需要网络专线带宽保障。大部分公司 MM2 就够用，RPO（丢多少数据）在秒级，RTO（恢复多久）在分钟级。记得定期做容灾演练，别等出了事才发现同步链路断了。
【面试题】10. 如果让你从零开始在一个新业务里落地 Kafka，你的完整流程是什么？
【标准答案】落地分六步走。第一步需求调研：搞清楚业务场景是数据管道（日志采集、埋点）还是业务消息（订单、通知），预估峰值 QPS 和数据量，确定消息可靠性要求。第二步容量规划：根据 QPS 和保留时间算需要的分区数和存储大小，一条消息算 1KB 的话，10 万 TPS 保留 7 天就是 60TB，规划 Broker 数量（建议 5-10 个物理机起步）。第三步 Topic 设计：确定分区数（宁多勿少，后面只能增不能减）、副本数（生产环境 3 副本）、清理策略（delete/compact）、消息 Key 设计保证顺序。第四步客户端规范：统一配置模板（acks=all、幂等开启、消费者手动提交），封装 SDK 统一拦截器（加 TraceId、异常告警），禁止业务方随意改参数。第五步监控告警：接入消费滞后、分区负载、Broker 系统资源等核心指标，消费积压超阈值就告警。第六步压测上线：用生产流量镜像压测一遍，关注延时分布和吞吐瓶颈，没问题再逐步切流量上线。关键是前两步需求调研和规范制定投入足够时间，这个阶段省的时间后面全变成事故处理时间。
生成时间：2026-06-18 22:17 覆盖考点：分区器机制、控制器、拦截器、Rebalance优化、消息顺序性、事务机制、零拷贝原理、Broker GC排查、高可用设计、项目0到1落地