Apache Kafka 面试应答指南

Apache Kafka 核心知识详解与面试应答指南

一、Apache Kafka 概述

Apache Kafka 作为一款分布式流处理框架，在实时构建流处理应用领域发挥着关键作用。其最广为人知的核心功能，便是作为企业级消息引擎被众多企业采用。

二、消费者组

（一）定义与原理

消费者组是 Kafka 独有的可扩展且具备容错性的消费者机制。它由多个消费者实例组成，这些实例共同订阅若干主题，实现消息的共同消费。同一消费者组下的每个实例配置相同的组 ID，并被分配到不同的订阅分区。当某个实例故障时，其他实例会自动接管其负责消费的分区，保障消息消费的连续性。

（二）面试策略

消费者组相关问题是面试中的高频考点，合理运用该知识点可引导面试方向。若擅长位移值原理，可阐述消费者组的位移提交机制；若对 Kafka Broker 熟悉，可探讨消费者组与 Broker 之间的交互；即便擅长 Producer，也可提及 “消费者组消费的数据源于 Producer 端生产的消息”，自然过渡到自身擅长领域。

三、ZooKeeper 在 Kafka 中的作用

当前，Kafka 依赖 ZooKeeper 完成集群元数据存放、成员管理、Controller 选举及其他管理任务。其中，“存放元数据” 是指主题分区的所有数据以 ZooKeeper 保存的数据为权威；“成员管理” 涵盖 Broker 节点的注册、注销及属性变更；“Controller 选举” 负责选举集群 Controller，其他管理任务包括主题删除、参数配置等。不过，随着 KIP-500 提案的推进，Kafka 未来将采用基于 Raft 的共识算法替代 ZooKeeper 实现 Controller 自选举，从而摆脱对 ZooKeeper 的依赖。在面试中提及 “目前” 这一现状，能体现对社区演进计划的了解，但抛出 KIP-500 也可能引发面试官进一步追问，需提前做好准备。

四、Kafka 中位移（offset）的作用

在 Kafka 中，每个主题分区下的每条消息都被赋予唯一的 ID 数值 —— 位移（偏移量），用于标识其在分区中的位置。消息写入分区日志后，位移值便不可修改。回答此问题后，可根据自身优势转移面试方向：若熟悉 Broker 底层日志写入逻辑，可强调消息在日志中的存放格式；若了解位移值的不可修改特性，可提及 “Log Cleaner 组件无法影响位移值”；若对消费者概念清晰，则可深入阐述位移值和消费者位移值之间的区别。

五、领导者副本（Leader Replica）和追随者副本（Follower Replica）

（一）基础区别

Kafka 副本分为领导者副本和追随者副本。只有 Leader 副本能对外提供读写服务，响应 Clients 端请求；Follower 副本通过拉（PULL）的方式同步 Leader 副本数据，并在 Leader 所在 Broker 宕机时，随时准备竞选成为 Leader。

（二）进阶加分项

在面试中，除基础区别外，还可补充两个加分要点。其一，自 Kafka 2.4 版本起，通过引入新的 Broker 端参数，Follower 副本已能有限度地提供读服务；其二，实际场景中，因程序 Bug、网络问题等多种因素，Leader 和 Follower 保存的消息序列可能不一致。此前依靠高水位机制确保一致性，但在 Leader 连续变更场景下存在弊端，为此社区引入了 Leader Epoch 机制进行修复。提及相对冷门的 Leader Epoch 机制，能展现更深入的技术理解。

六、实操题目

（一）设置 Kafka 能接收的最大消息大小

设置 Kafka 接收的最大消息大小，需同时配置 Broker 端和 Consumer 端参数。Broker 端参数包括 message.max.bytes、max.message.bytes（主题级别）和 replica.fetch.max.bytes；Consumer 端参数为 fetch.message.max.bytes。其中，Broker 端的 replica.fetch.max.bytes 参数常被遗漏，正确回答可作为加分项，因为它关系到 Follower 副本接收消息的能力，影响副本同步。

（二）监控 Kafka 的框架

Kafka Manager：最知名的专属 Kafka 监控框架，独立运行。

Kafka Monitor：LinkedIn 开源的免费框架，支持集群系统测试与实时监控结果查看。

CruiseControl：同样由 LinkedIn 开源，用于实时监测资源使用率，提供常用运维操作，通过 REST API 交互，无 UI 界面。

JMX 监控：Kafka 监控指标基于 JMX，可集成 JMX 的框架如 Zabbix 和 Prometheus 均可用于监控。

大数据平台监控体系：如 Cloudera 的 CDH 等大数据平台，自带 Kafka 监控方案。

JMXTool：社区提供的命令行工具，能实时监控 JMX 指标，知晓该工具可给面试官留下对 Kafka 工具熟悉的印象，若不熟悉用法，可通过执行 kafka-run-class.sh kafka.tools.JmxTool 学习。

（三）设置 Broker 的 Heap Size

设置 Heap Size 是通用的面试问题，回答时建议先简述 Java 进程 JVM 堆大小的常规设置方法：以默认初始 JVM 堆大小运行程序，系统稳定后手动触发 Full GC，通过 JVM 工具查看 GC 后存活对象大小，再将堆大小设为存活对象总大小的 1.5 – 2 倍。对于 Kafka Broker，此方法同样适用，但业界最佳实践是将 Broker 的 Heap Size 固定为 6GB，该大小已在众多公司得到验证。

（四）估算 Kafka 集群的机器数量

估算 Kafka 集群机器数量需从磁盘空间和带宽占用两方面评估。预估磁盘占用时，要考虑副本同步开销，例如一条 1KB 消息在 3 副本主题中需 3KB 总空间存储；评估带宽时，需与面试官确认给定带宽，明确指出当带宽占用接近总带宽 90% 时会出现丢包，体现网络方面的专业知识。

（五）解决 Leader 总是 -1 的问题

生产环境中，当主题分区无法工作且查看状态发现 Leader 为 -1 时，避免直接回答 “重启集群”。正确解决方案是删除 ZooKeeper 节点 /controller，触发 Controller 重选举。Controller 重选举能重刷所有主题分区状态，有效解决因不一致导致的 Leader 不可用问题。

七、炫技式题目

（一）LEO、LSO、AR、ISR、HW 的含义

LEO（Log End Offset）：日志末端位移值，指日志下一条待插入消息的位移值。

LSO（Log Stable Offset）：Kafka 事务概念，控制事务型消费者可见消息范围，与日志起始位移值易混淆，需注意区分。

AR（Assigned Replicas）：主题创建后，分区创建时分配的副本集合，副本数量由副本因子决定。

ISR（In-Sync Replicas）：AR 中与 Leader 保持同步的副本集合，Leader 副本天然包含其中。判断副本是否属于 ISR 的依据是 Follower 副本的 LEO 落后 Leader LEO 的时间是否超过 Broker 端参数 replica.lag.time.max.ms 值。

HW（高水位值，High watermark）：控制消费者可读取消息范围，普通消费者只能读取 Leader 副本上介于 Log Start Offset 和 HW（不含）之间的消息。

（二）Kafka 手动删除消息

Kafka 自身提供留存策略自动删除过期消息，但也支持手动删除。对于设置了 Key 且参数 cleanup.policy=compact 的主题，可构造 <Key，null> 消息发送给 Broker，借助 Log Cleaner 组件删除该 Key 的消息；对于普通主题，可使用 kafka-delete-records 命令或编写程序调用 Admin.deleteRecords 方法，其底层均通过抬高分区 Log Start Offset 值间接删除消息。

（三）__consumer_offsets 的作用

__consumer_offsets 是 Kafka 的内部主题，虽官网资料涉及较少，但却是面试中的重要考点。该主题由 Kafka 自行管理（也可创建），主要负责注册消费者及保存位移值，同时也是保存消费者元数据（包括消费者组和独立消费者）的地方。Kafka 的 GroupCoordinator 组件对其进行完整管理，涵盖创建、写入、读取和 Leader 维护等操作。

（四）分区 Leader 选举策略

Kafka 分区 Leader 副本选举由 Controller 独立完成，共有 4 种选举策略：

OfflinePartition Leader 选举：分区上线（如新分区创建或下线分区重新上线）时执行。

ReassignPartition Leader 选举：手动运行 kafka-reassign-partitions 命令或调用 Admin 的 alterPartitionReassignments 方法执行分区副本重分配时触发。

PreferredReplicaPartition Leader 选举：手动运行 kafka-preferred-replica-election 命令或自动触发 Preferred Leader 选举时激活，Preferred Leader 为 AR 中的第一个副本。

ControlledShutdownPartition Leader 选举：Broker 正常关闭时，Broker 上所有 Leader 副本下线，需为受影响分区执行选举。这 4 类选举策略通常从 AR 中挑选首个在 ISR 中的副本作为新 Leader，虽存在微小差异，但回答到此程度基本可应对面试。

（五）Kafka 中零拷贝（Zero Copy）的使用场景

Zero Copy 是 Kafka 面试中的高阶问题，其使用场景主要有两处：一是基于 mmap 的索引，通过让用户态和内核态共享内核态数据缓冲区，避免数据复制到用户态空间，但因不同操作系统下 mmap 创建和销毁成本存在不确定性，Kafka 仅在索引中应用，核心日志未采用；二是 Kafka 传输层接口 TransportLayer 的部分实现类使用 FileChannel 的 transferTo 方法，该方法底层通过 sendfile 实现 Zero Copy，当 I/O 通道为 PLAINTEXT 时，Kafka 可利用此特性直接将页缓存数据发送到网卡 Buffer，若启用 SSL 则无法使用。

八、深度思考题

（一）Kafka 不支持读写分离的原因

实际上，自 Kafka 2.4 版本后，已提供有限度的读写分离，Follower 副本可对外提供读服务。在此之前不支持读写分离，主要原因包括：一是 Kafka 的应用场景与读写分离适用场景不匹配，读写分离更适合读负载大、写操作不频繁的场景，而 Kafka 并非如此；二是 Kafka 采用 PULL 方式实现 Follower 同步，导致 Follower 与 Leader 存在不一致性窗口，若允许读 Follower 副本，需处理消息滞后问题。

（二）如何调优 Kafka

调优 Kafka 的首要步骤是明确优化目标并量化，常见目标包括吞吐量、延时、持久性和可用性，不同目标的优化思路不同。确定目标后，需明确优化维度，涵盖通用优化（如操作系统、JVM 优化）和针对性优化（如提升 Kafka TPS）。具体可从 Producer 端（增加 batch.size、linger.ms，启用压缩，关闭重试等）、Broker 端（增加 num.replica.fetchers，提升 Follower 同步 TPS，避免 Broker Full GC 等）和 Consumer 端（增加 fetch.min.bytes 等）进行调整。

（三）Controller 发生网络分区时 Kafka 的情况

当 Controller 发生网络分区时，首先应依据 Broker 端监控指标 ActiveControllerCount 判断集群是否出现 “脑裂”。由于 Controller 会向 Broker 发送 LeaderAndIsrRequest、StopReplicaRequest 和 UpdateMetadataRequest 三类请求，网络分区会导致这些请求无法正常到达 Broker 端，进而影响主题的创建、修改、删除操作的信息同步，使集群仿佛停滞，无法响应后续操作，因此需尽快修复。

（四）Java Consumer 采用单线程获取消息的原因

Java Consumer 采用双线程设计，其中用户主线程负责获取消息，心跳线程负责向 Kafka 汇报消费者存活情况，将心跳单独置于专属线程可避免因消息处理慢导致的 “假死” 误判。单线程获取消息采用轮询方式，易于实现异步非阻塞，便于将消费者扩展为支持实时流处理的操作算子，同时还能简化代码开发，降低多线程交互带来的错误风险。

（五）Follower 副本消息同步的完整流程

Follower 副本消息同步流程如下：首先，Follower 向 Leader 发送 FETCH 请求；Leader 收到请求后，读取底层日志文件消息数据，更新内存中 Follower 副本的 LEO 值为 FETCH 请求中的 fetchOffset 值，并尝试更新分区高水位值；Follower 接收到 FETCH 响应后，将消息写入底层日志，随后更新自身的 LEO 和 HW 值。由于 Leader 和 Follower 的 HW 值更新时机不同，Follower 的 HW 更新滞后于 Leader，这种时间差是导致不一致问题的根源之一。

以上从多方面梳理了 Kafka 面试要点。你可说说是否对某些内容想进一步拓展，或有特定修改需求，我继续完善。