Kafka 面试题（2026-06-18）
【面试题】1. Kafka 生产者的拦截器（Interceptor）是干什么的？有哪些实战场景？
【标准答案】拦截器是生产者发送链路中的"钩子"，在消息序列化后、分区计算后、发送前、收到回调后等节点插入自定义逻辑。实现了 ProducerInterceptor 接口两个关键方法：onSend()——消息发出去之前调，你可以改消息内容、加 Header、打埋点；onAcknowledgement()——收到 Broker 的 ACK 后调，能拿到 offset 和异常信息。实战场景：一、全链路追踪——在 onSend() 里往消息 Header 塞 traceId，下游消费者能串联整条链路；二、发送审计——在 onAcknowledgement() 里统计成功/失败数，写监控打点，不用散落在业务代码里；三、消息脱敏——在 onSend() 里对手机号、身份证做掩码再发出去；四、限流——onSend() 里做漏桶或令牌桶计数，超阈值直接抛异常阻止发送。拦截器是链式调用的，可以有多个但要注意顺序。坑：拦截器里别做重操作，它跑在生产者的发送线程上，阻塞了就影响整体吞吐。
【面试题】2. Kafka 主题的分区数怎么定？多了少了各自会踩什么坑？
【标准答案】分区数的核心公式：max(预期吞吐 / 单分区吞吐, 消费者并发数)。单分区吞吐取决于 Producer 的 batch 效率、消息大小、磁盘性能，通常一个分区能跑到几十 MB/s。少了的问题：一、并发上不去——消费者数不能超过分区数，加机器白加；二、单分区写入热点——如果按 Key 分区且 Key 分布不均，某些分区磁盘打满别的还空着；三、Broker 负载不均——在集群扩容时新 Broker 分不到 Leader 因为分区太少。多了的问题：一、文件句柄爆炸——每个分区对应大量 Segment 文件，分区多了 Broker 的 FD 撑不住；二、Controller 压力——Leader 选举、ISR 变更都是分区维度的，分区越多 Controller 越忙，大规模宕机时恢复慢；三、端到端延迟增加——太多分区意味着 Producer 和 Consumer 需要维护更多 TCP 连接和元数据缓存。经验法则：单 Broker 分区数控制在 2000-4000 以内，单集群 20 万分区是上限。宁多勿少但要留余地。
【面试题】3. Kafka 日志清理策略 delete 和 compact 区别是什么？什么场景该用 compact？
【标准答案】delete 是按时间或大小删数据——超过 retention.ms 或者 Segment 总大小超过 retention.bytes 的直接整个文件删掉，不管你消息里存的啥。compact 特殊得多：它保留每个 Key 的最新值，旧的同 Key 消息会被清理掉。原理是后台 Cleaner 线程扫描日志，遇到同一个 Key 的多条消息只保留最后一条，其余物理删除。适用场景：一、数据库 CDC——binlog 的变化日志用表主键做 Key，compact 后永远能拿到每行数据的最新状态，适合做缓存更新、索引重建；二、Kafka 内部就靠 compact——__consumer_offsets 存消费位移就是 compact topic，每个消费组的分区位移永远只保留最新值。不该用 compact 的场景：消息不需要 Key（Key=null 的消息 compaction 时全保留不删导致无限膨胀）、埋点日志、时序数据。注意 compact 不保证"刚好一条就清理"，它按 Segment 的脏数据比率渐进清理，可能延迟几分钟到几小时。
【面试题】4. ISR 收缩和扩展的动态过程是怎样的？什么情况会导致 ISR 剧烈抖动？
【标准答案】ISR 收缩靠 replica.lag.time.max.ms（默认 30s）：Follower 超过这个时间没同步到 Leader 的最新数据，就被踢出 ISR。这里有两个细节——不是看 Follower 落后多少条消息，而是看"最后一次同步请求"到现在过了多久，只要 Follower 还在持续发 fetch 请求即使慢点也不会被踢。ISR 扩展靠 Follower 追平 Leader 的 LEO：当 Follower 的消息追上 Leader 的末尾，且在 replica.lag.time.max.ms 内向新 Leader 发出了 fetch 请求，Leader 就把它加回 ISR。ISR 剧烈抖动常见原因：一、磁盘 IO 打满——某个 Broker 的盘在合并刷盘或备份任务，Follower 同步变慢→被踢→IO 恢复→又追上→加回来，反复横跳；二、GC 停顿——Full GC 把 Follower 线程暂停了几十秒，醒来后落后一大截被踢出 ISR；三、网络抖动——Broker 之间的网络间歇性丢包或延迟飙高。解决：把 replica.lag.time.max.ms 从 30s 调到 60s 给点缓冲，排查那个 Broker 为什么慢——可能是硬件问题或别的进程抢 IO。
【面试题】5. Kafka Controller 控制器到底管什么？它挂了集群会怎样？
【标准答案】Controller 是集群的"大脑"，一个集群同一时刻只有一个 Broker 担任这个角色。职责清单：一、分区 Leader 选举——某个 Broker 宕机了，Controller 从该 Broker 上所有分区的 ISR 里选新 Leader，然后通知所有 Broker 更新元数据；二、Broker 上下线管理——新 Broker 加入时分配分区给它、Broker 退出时迁移 Leader；三、分区重分配——运维操作用 kafka-reassign-partitions.sh 迁移分区时 Controller 驱动整个过程；四、Topic 增删——创建 Topic 时 Controller 分配分区到 Broker、删除 Topic 时协调各 Broker 清理数据。Controller 自身靠 ZK 临时节点选举（老版本）或 KRaft 的 Raft 协议（新版本）。Controller 挂了的影响：如果用的是 ZK 模式，ZK session 超时后触发热选举，这个窗口内分区 Leader 切换无法执行（比如某个 Broker 刚挂），新消息写到老 Leader 所在 Broker 会失败直到新 Controller 选出。选举通常在几秒内完成，配合 unclean.leader.election.enable=false 确保不选 ISR 外的副本。
【面试题】6. Kafka 生产者开启幂等后，Broker 是怎么保证"同一条消息不重复落盘"的？PID 和 Sequence Number 的机制是怎样的？
【标准答案】这是 Kafka 幂等的核心面试点。开启 enable.idempotence=true 后：第一步，Producer 启动时向 Broker 申请一个 PID（Producer ID），全局唯一，生命周期在 Producer 重启前不变。第二步，发往每个分区的每条消息带一个从 0 单调递增的 Sequence Number。第三步，Broker 端在内存里为每个 PID+TopicPartition 维护 5 个最近的 SeqNumber，收到消息时检查：如果消息 SeqNumber 比 Broker 记录的 lastSeqNumber 大 1——正常，写入并更新 lastSeqNumber；如果消息 SeqNumber ≤ lastSeqNumber——说明是重试重复，直接丢弃但返回成功 ACK；如果消息 SeqNumber > lastSeqNumber + 1——说明中间丢消息了，报 OutOfOrderSequenceException 拒绝写入。这样就解决了单个 Producer 会话内的重复和乱序问题。关键限制：幂等只对同一个 PID 生效，Producer 重启后换新 PID 就没法排重了——所以才需要事务（Transactional ID）来跨会话保证。而且幂等只在单分区内有效，跨分区不保证。
【面试题】7. 生产者参数 batch.size 和 linger.ms 怎么配合调优才能在不丢消息的前提下提到最高吞吐？
【标准答案】batch.size 是攒批的内存上限（默认 16KB），linger.ms 是最多等多久就得把批发出去（默认 0）。两者是一个"或"的关系——批满了或时间到了就发。调优思路：linger.ms 是核心，从 0 改成 5-10ms 能让好几条消息攒成一个批，吞吐瞬间翻倍，延迟只增加几毫秒。batch.size 从 16KB 调大到 512KB 或 1MB 能让批更"肥"，减少网络往返。但 batch.size 不能无限大：一、要小于 Producer 的 buffer.memory（默认 32MB）不然 OOM；二、要考虑消息大小的压缩比，如果消息本身 1KB，batch 攒 512 条就 512KB 了，压缩后可能更小，批越大压缩效果越好。配合参数：compression.type 开 snappy 或 lz4，压缩率通常 3-5 倍，相当于变相增大 batch 容量。注意 linger.ms 开大了加上 delivery.timeout.ms 兜底——如果 linger 等太久导致超时发送失败，需要权衡。最终版：batch.size=1MB、linger.ms=10ms、compression.type=lz4，单分区吞吐轻松上 50MB/s 且延迟在 15ms 内。必须配合 acks=all+retries 兜底不丢。
【面试题】8. 生产环境 Kafka 必须监控哪些指标？什么样的告警规则才算合理？
【标准答案】监控分四层。第一层系统层：CPU、磁盘 IO util%、磁盘使用率、网络吞吐。磁盘使用率超过 70% 就得准备扩容，超过 85% 告警。第二层 Broker 层：UnderReplicatedPartitions > 0 意味着有分区副本没同步完，可能丢数据；ActiveControllerCount ≠ 1 说明 Controller 脑裂；OfflinePartitionsCount > 0 分区全挂；RequestQueueSize 持续增长说明 IO 线程忙不过来；NetworkProcessorAvgIdlePercent < 0.3 网络线程吃紧。第三层消费层：ConsumerGroup Lag——最重要指标。告警规则不是死板地"Lag > 1000 报警"，而是看 Lag 增长率——5 分钟内 Lag 持续上升 20% 且无回降趋势才报警，避免短时抖动误报。第四层生产者层：record-error-rate（发送错误率）、record-retry-rate（重试率）、request-latency-avg（平均延迟）。告警经验：分级告警——P0 是 UnderReplicatedPartitions > 0 或 OfflinePartitions > 0，P1 是 Lag 持续增长，P2 是磁盘或 CPU 告警。不要设太多告警，告警疲劳比没告警更可怕。
【面试题】9. 线上消费组大面积 Rebalance 风暴，几百个消费组同时重平衡导致集群雪崩，怎么排查和治理？
【标准答案】大面积 Rebalance 风暴通常由两个根因之一触发。病因一：Broker 滚动重启或网络故障导致 Consumer 心跳集体超时。几十个消费组的几千个消费者同时重新 JoinGroup，Controller 和 GroupCoordinator 的请求队列瞬间爆炸，CPU 飙到 100%，元数据更新卡死，正常读写都受影响。病因二：某个核心 Topic 的分区数变更，导致所有消费该 Topic 的消费者组被迫 Rebalance。排查路径：一、看 Broker 日志有没有大量 "Preparing to rebalance group"；二、查监控看哪个时间点所有消费的 Lag 都跳变（消费者停消费的标志）；三、用 kafka-consumer-groups.sh 看 Rebalance 频率。治理方案：短期——把 session.timeout.ms 调大到 60-90s，heartbeat.interval.ms 调大，给 Broker 恢复争取时间；CooperativeSticky 分区策略做增量 Rebalance 减少全停。长期——Consumer 限流、分批重启 Broker、大集群控制单 Broker 的消费者连接数。核心原则：别把所有鸡蛋放一个篮子——大集群要分组分批运维，不要一次性让所有消费者都经历重平衡。
【面试题】10. 如果要设计一个跨机房双活的 Kafka 方案，你会怎么搞？Kafka 本身能搞定吗？
【标准答案】实话实说，Kafka 原生不支持跨机房双活——它的设计假设是副本在同一集群内同步，跨地域的网络延迟（几十上百 ms）会让 ISR 机制崩盘。业界主流方案分三层：方案一（简单版）——MM2（MirrorMaker 2），在机房 A 部署主集群，机房 B 部署备集群，MM2 异步同步数据。缺点是有延迟（秒到分钟级），机房切换时有数据丢失窗口。方案二（应用层双写）——生产者同时写两个机房的 Kafka 集群，消费者读本地集群。好处是零 RPO 零 RTO，问题是应用侧要处理幂等和部分失败（一个集群写成功另一个失败怎么办？）。方案三（多集群路由）——用 Apache Pulsar 或自研路由层，内置 Geo-Replication，比 Kafka 更适合多活。实际落地建议：大多数公司不需要真双活，成本太高——用 Kafka 主备方案（同步磁盘级复制或者 MM2 + 快速 DNS 切换），RPO 控制在秒级、RTO 控制在分钟级，性价比最高。如果真有零 RPO 需求，考虑 RocketMQ 或 Pulsar 的原生多活方案，别硬上 Kafka。
生成时间：2026-06-18 22:54 覆盖考点：生产者拦截器、主题分区规划、日志清理策略(delete/compact)、ISR收缩与扩展、Controller控制器、生产者幂等性(PID+SeqNumber)、性能调优(batch.size/linger.ms/compression)、监控与运维(核心指标与告警)、消费组Rebalance风暴排查、多机房容灾方案