Kafka 面试考察的是你是否理解数据如何在日志中流转：topic 如何拆分为 partition、你能依赖怎样的顺序保证、consumer 如何分担工作，以及出故障时会发生什么。关于 lag、重复消息和数据丢失的场景题很常见，因为这些正是生产环境中会遇到的问题。
以下是 22 道面试题及参考答案。默认值等细节在不同 Kafka 版本之间会有差异，所以记得提到你会先确认所用的版本。
核心概念
1. Kafka 是什么，用来做什么？
Kafka 是一个分布式、可复制的提交日志（commit log）。Producer 向 topic 追加记录，consumer 按自己的节奏读取。它用于事件流处理、日志和指标管道、服务解耦、向分析系统输送数据，以及流处理。
2. topic、partition 和 offset 分别是什么？
topic 是一个有名字的记录流。每个 topic 被拆分为多个 partition，每个 partition 是一个有序的、只能追加的日志。partition 中的每条记录都有一个 offset，即标识其位置的一个顺序编号。offset 只在同一个 partition 内唯一。
3. partition 如何影响顺序？
Kafka 只保证 partition 内的顺序。默认情况下，相同 key 的记录会进入同一个 partition，因此它们之间的相对顺序得以保持。跨 partition 则没有顺序保证。如果你需要某个客户的所有事件按顺序处理，就用客户 ID 作为 key。
4. broker 是什么，controller 做什么？
broker 是一台存储 partition 并为客户端提供服务的 Kafka 服务器。一个集群有多台 broker。其中一台担任 controller，负责管理集群元数据和 partition leader 选举。较新的 Kafka 版本使用 KRaft——一种内置的共识机制——来管理这些元数据，而不再依赖 ZooKeeper。
5. 副本（replication）是如何工作的？
每个 partition 都有一个副本因子（replication factor）。其中一个副本是 leader，负责处理读写，其余是 follower，负责复制 leader 的数据。同步副本（ISR）是指那些跟上了 leader 进度的副本。如果 leader 故障，会从 ISR 中选出新的 leader。
Producer
6. acks 各个设置分别是什么意思？
| acks | 含义 | 权衡 |
|---|---|---|
| 0 | Producer 不等待任何确认 | 最快，可能丢数据 |
| 1 | Leader 写入后确认 | 如果 leader 在复制完成前故障，可能丢数据 |
| all | Leader 等待所有同步副本确认 | 持久性最强，延迟更高 |
要保证写入持久，使用 acks=all，同时把 min.insync.replicas 设为至少 2，副本因子设为 3。
7. 如何避免 producer 产生重复消息？
启用幂等 producer（enable.idempotence=true），这样 broker 会丢弃同一 partition 内因重试产生的重复消息。对于必须跨多个 partition 或 topic 原子写入的场景，使用事务。
8. producer 如何选择 partition？
如果你指定了 key，默认分区器会对它做哈希来选定 partition。如果没有 key，producer 会把记录分散到各个 partition（较新版本采用粘性策略以高效填满批次）。你也可以编写自定义分区器。
9. 哪些因素影响 producer 吞吐量？
批处理（batch.size、linger.ms）、压缩（如 lz4 或 zstd）、partition 数量，以及 acks。更大的批次和压缩通常能提高吞吐量，代价是略微增加延迟。
消费者
10. 什么是消费者组？
一组消费者共同分担读取某个主题的工作。每个分区在同一时刻只会分配给组内的一个消费者。因此，一个组内真正有用的消费者数量受分区数量限制，多出来的消费者只能闲置。
11. 重平衡期间会发生什么？
当有消费者加入或离开，或者分区发生变化时，组会重新分配分区。在经典重平衡过程中，消费会暂停。协作式重平衡和静态成员机制可以减少这种干扰。频繁的重平衡通常是因为消费者处理时间过长（max.poll.interval.ms）或心跳丢失。
12. 偏移量是如何提交的？
消费者提交下一条要读取记录的偏移量，存储在内部主题中。自动提交很简单，但可能在处理完成前就提交了。在处理完成后手动提交，可以让你自己定义什么算“完成”。
13. 至多一次、至少一次和精确一次分别是什么意思？
- 至多一次：先提交偏移量再处理。崩溃可能导致记录丢失。
- 至少一次：先处理再提交。崩溃可能导致重复处理，所以可能出现重复。
- 精确一次：效果只发生一次。在 Kafka 内部，可以通过幂等生产者、事务和 read_committed 消费者实现。当写入外部系统时，通常需要幂等写入或按 key 去重。
一个好的回答会指出，“精确一次”取决于副作用发生在哪里。
14. 如何处理一条总是失败的有毒消息？
捕获错误，有限次重试，然后把记录连同详细信息发送到死信主题，提交偏移量，继续处理。对死信主题设置告警，让相关人员去排查。
运维与场景
15. 消费者延迟在增长，如何诊断？
- 检查哪些分区有延迟。单个热点分区通常指向 key 分布不均。所有分区都有延迟则说明处理太慢或消费者太少。
- 检查每条记录的处理时间以及下游调用（比如数据库）。
- 检查是否有频繁的重平衡。
- 检查生产者的发送速率是否上升。
- 通过增加消费者（最多到分区数量）、加快处理、批量处理或增加分区来解决。
16. 什么时候应该增加分区数量？
当你需要的并行度超过现有消费者能提供的，或者每个分区的吞吐量成为瓶颈时。要注意：增加分区会改变新记录的 key 到分区的映射，所以某个 key 的顺序可能在变更前后被打乱。如果顺序很重要，要提前规划好分区数量。
17. 数据是如何保留的？什么是日志压缩？
默认情况下，Kafka 按时间或大小删除旧段（retention.ms、retention.bytes）。使用日志压缩时，Kafka 会为每个 key 至少保留最新的值，适合变更日志或类表主题。null 值（墓碑记录）表示该 key 被标记为删除。
18. 如果 broker 故障了会怎样？
由该 broker 领导的分区会从 ISR 中选出新的 leader。客户端刷新元数据后继续工作。如果没有可用的同步副本，分区将不可用，除非你允许非干净 leader 选举，但这有数据丢失的风险。
19. 如何保护 Kafka 集群的安全？
传输加密用 TLS，身份认证用 SASL（比如 SCRAM 或 OAuth）或双向 TLS，授权用 ACL 控制主题和组的访问，再加上网络控制。如有需要，在应用层对敏感字段加密。
20. 如何监控 Kafka？
关键信号包括消费者延迟、副本不足的分区、离线分区、请求延迟、磁盘使用量，以及 ISR 收缩和扩展速率，通过 JMX 指标和 Prometheus、Grafana 等工具采集。
设计题
21. 什么时候你会选择 Kafka 而不是 RabbitMQ 或 SQS 这样的消息队列？
当你需要高吞吐、回放历史事件、多个独立消费者消费同一数据流，或者流处理时，选择 Kafka。当你需要按消息路由、简单的任务队列，或者不想管理分区时，选择传统队列。
22. 设计一个订单事件管道。
“订单发送到以订单 ID 为 key 的 orders 主题，这样同一个订单的事件能保持顺序。我会用三个或更多 broker，复制因子为 3，acks=all，并使用幂等生产者。计费、库存和分析的消费者各自使用自己的组。计费写入按订单 ID 幂等，失败的记录进入死信主题，我会按组监控延迟。分区数量根据峰值吞吐量和预期消费者数量来定，并留出增长空间。”
如何准备
如果可以的话，在本地跑一个 Kafka，写一个生产者和一个消费者组，停掉一个消费者，观察重平衡的过程。故意搞坏点东西，比如让消费者变慢，看看 lag 的变化。准备一个你解决过的数据管道问题的真实案例。相关话题可以参考我们的 Databricks 和系统设计面试指南。
练习把投递保证大声讲出来，因为这里最容易答得含糊。做一次模拟面试并录音复盘，就能看出问题在哪。在任何实时面试中，都要遵守雇主关于 AI 工具的规定。
使用 YesToTheOffer 练习 Kafka 面试答案
进行一次模拟技术面试，大声解释投递保证，并在之后查看你的记录。30 分钟免费，无需订阅。
