Kafka 面试通常会问哪些问题？

你已经知道 Kafka 是分布式日志，但担心面试官会比你的日常使用再深入一层。这恰好就是这些问题的方向，因此本节会按照面试官通常采用的顺序梳理相关术语，并指出每个术语背后的追问。

• 主题和分区。主题会被拆分为多个分区，每个分区都是仅追加的有序日志。追问：为什么 Kafka 通过增加分区来扩展写入能力，而不是让单个日志写得更快？
• 偏移量。消费者在分区中的位置。追问：已提交的偏移量由谁存储？如果消费者在提交前崩溃，会发生什么？
• 消费者组。同一组中的消费者共享某个主题的分区，同一时刻每个分区最多分配给组内一个消费者。追问：如果组内消费者数量多于分区数量，吞吐量会怎样？
• 代理和控制器。代理存储分区；控制器负责领导者选举和元数据。追问：Kafka 将元数据从 ZooKeeper 迁移到 KRaft 后发生了哪些变化？
• 生产者和键。带键的消息会根据键的哈希值进入选定分区；不带键的消息则会分散到多个分区。追问：这两种方式中，哪一种能保持同一客户事件的顺序？

回答这些问题时要说明机制，而不能只喊口号。说分区能够实现并行处理只是基本要求；解释顺序仅存在于分区内部，因此键决定了顺序范围，才是能让你进入下一轮的答案。

大多数候选人会在这一层失分，因为术语很简单，权衡却不简单。面试官通常会指定一种保证，并要求你通过配置来实现它。

• 至多一次与至少一次。如果先提交偏移量再处理消息，就可能丢失消息；如果先处理再提交，就可能重复处理消息。你需要说明每种顺序能够容忍哪种故障，以及你的系统倾向于哪一种。
• 幂等生产者和恰好一次。幂等生产者会对分区内的重试去重；事务则将这一能力扩展到多个分区，并覆盖“消费—转换—生产”循环中的消费者偏移量。你还要准备说明恰好一次不涵盖什么：事务之外对下游数据库的写入仍需由你处理。
• acks、复制因子和同步副本。acks=all会等待同步副本集合；min.insync.replicas规定该集合缩小到什么程度后必须拒绝写入。面试官经常会问，为实现这种持久性需要牺牲什么：即代理故障期间的延迟和可用性。
• 保留和压缩。按时间或大小执行的保留策略会删除旧日志段；日志压缩则保留每个键对应的最新记录。追问：哪一种适合为键值存储提供变更日志？为什么？
• 再均衡。当消费者加入或离开时，系统会重新分配分区。追问：漫长的再均衡会对延迟敏感型服务造成什么影响？协作式再均衡和静态成员机制如何减轻这一问题？

一个实用习惯是：每提到一项设置，都说明它能防止哪种故障，以及会增加什么成本。这样的结构能让你一口气回答原问题和后续追问。

高级职位的面试会用场景取代定义，并观察你的推理过程。一个典型题目是：某位后端工程师正在面试支付公司的平台岗位，需要设计一条事件管道，要求同一账户的每笔交易都按顺序处理、吞吐量能够随流量增长，而且代理停机时不能丢失数据。优秀的答案会按账户 id 设置消息键，使同一账户的事件进入同一分区；根据预期峰值估算分区数量并为增长预留空间；通过复制和 acks=all保证持久性；还会解释消费者应如何提交偏移量，使崩溃后能够重放消息而不是跳过消息。

其他常见场景包括：消费者落后时如何检测延迟并追赶进度；发现某个主题的分区数量设置不当，以及重新分区为何会破坏基于键的顺序；导致消费者崩溃的有害消息，以及用于隔离它的死信模式；生产者与消费者之间的模式变更，以及模式注册表能带来什么价值。面试官并非只寻找一种正确架构。他们希望你指出约束、选择机制，并明确说出其中的权衡。

面试前要大声练习这些问题，而不只是阅读。使用会继续追问的 AI 面试官排练场景题，正是模拟面试页面中练习模式的用途；更完整的职位和主题题库位于按职位和主题分类的面试问题页面。

在对话式面试中可以，但需要遵守诚信边界。SubcueAI 的原生 macOS 和 Windows 桌面应用会采集面试官的音频和你的麦克风音频，并在本地浮层中显示简短的答案建议。因此，当面试官询问 min.insync.replicas能够防范什么时，相关机制会显示在屏幕上，供你用自己的话解释。浏览器扩展可在浏览器标签页中的通话里实现同样的功能，并且只采集会议标签页的音频。两者都不会向通话中添加机器人，也不会向会议页面注入任何内容；设置步骤请参阅教程页面。

适用限制比宣传卖点更重要。监考式编程测试、录屏测试或使用公司管理的笔记本电脑进行的测试都不在适用范围内；如果你需要在他人观察下实现消费者，实时编程练习也必须由你独立完成。该助手最适合处理上述术语和权衡问题，最不适合需要在测评平台中输入答案的任务。在依赖它之前，请导入你的简历，让建议能够反映你实际完成过的 Kafka 工作；这份资料位于简历生成器页面。