一文带你掌握Kafka常见面试题

Kafka 常见八股面试题：架构、可靠性、顺序性、消息积压一篇讲透

这篇文章按图片里的问题整理 Kafka 面试高频题。目标不是把源码背下来，而是能用通俗的话讲清楚：Kafka 是什么、为什么快、消息为什么会丢或重复、顺序性怎么保证、线上消息积压怎么排查。

一、Kafka 基础与架构

1. Kafka 是什么？核心定位与核心价值是什么？

Kafka 是一个分布式消息队列，也可以叫分布式事件流平台。它最常见的用途是做系统解耦、异步处理、削峰填谷、日志采集和实时数据流转。

Kafka 的核心定位不是“简单发一条消息给消费者”，而是高吞吐、可持久化、可扩展的消息流系统。

它的核心价值：

• 解耦：生产者和消费者不用直接依赖。
• 异步：耗时操作可以通过消息异步处理。
• 削峰：流量高峰先写入 Kafka，消费者按能力慢慢处理。
• 广播：一个 Topic 可以被多个消费组分别消费。
• 可回溯：消息保留一段时间后，消费者可以按 offset 重新消费。
• 高吞吐：适合日志、埋点、订单事件、同步任务等海量消息场景。

一句话：Kafka 更像一个高性能、可持久化、可扩展的消息日志系统。

2. Kafka 核心架构组成有哪些？Producer、Consumer、Broker 等核心作用？

Kafka 常见核心组件：

• Producer：生产者，负责发送消息到 Kafka。
• Consumer：消费者，负责从 Kafka 拉取并处理消息。
• Broker：Kafka 服务节点，一台 Kafka 服务器就是一个 Broker。
• Topic：主题，消息的逻辑分类。
• Partition：分区，Topic 的物理拆分单位。
• Replica：副本，用于高可用。
• Consumer Group：消费组，同一个组内多个消费者共同消费一个 Topic。
• Controller：集群控制者，负责分区 leader 选举等管理工作。

生产者把消息发到某个 Topic 的某个 Partition，Broker 负责存储消息，消费者按消费组从 Partition 中拉取消息并提交 offset。

3. Topic、Partition、Replica 三者的核心关系是什么？各自作用是什么？

Topic 是逻辑概念，用来区分业务消息类型，比如 order_topic、user_log_topic。

Partition 是 Topic 的分片。一个 Topic 可以有多个 Partition，每个 Partition 内部消息是有序追加的。

Replica 是 Partition 的副本。每个 Partition 可以有多个副本，其中一个是 Leader，其他是 Follower。

关系可以这样理解：

Topic -> 多个 Partition -> 每个 Partition 有多个 Replica

各自作用：

• Topic：业务分类。
• Partition：提升并发和吞吐，支持水平扩展。
• Replica：提升可用性，Broker 宕机后仍能继续服务。

面试重点：Kafka 只保证单个 Partition 内有序，不保证多个 Partition 全局有序。

4. Kafka 为什么吞吐量极高？核心优化机制有哪些？

Kafka 高吞吐不是靠单一技术，而是一组工程优化叠加出来的。

核心原因：

第一，顺序写磁盘。Kafka 消息以追加方式写入日志文件，顺序写比随机写快很多。

第二，Page Cache。Kafka 大量依赖操作系统页缓存，数据先写入内存缓存，再由系统刷盘。

第三，零拷贝。消费者读取消息时，可以通过 sendfile 等机制减少用户态和内核态之间的数据拷贝。

第四，批量发送。Producer 会把多条消息合并成批次发送，减少网络请求次数。

第五，压缩。支持 gzip、snappy、lz4、zstd 等压缩，减少网络和磁盘 IO。

第六，分区并行。多个 Partition 可以分布到多个 Broker 上，实现并行写入和消费。

第七，拉模式消费。Consumer 自己控制拉取速度，Broker 压力更可控。

一句话：Kafka 快，主要靠顺序写、Page Cache、零拷贝、批量压缩和分区并行。

5. Kafka 适用场景与不适用场景分别是什么？

适用场景：

• 日志采集。
• 用户行为埋点。
• 订单、支付、库存等业务事件流。
• 异步解耦。
• 削峰填谷。
• 实时数仓、Flink/Spark Streaming 数据源。
• 多系统数据同步。

不适用场景：

• 极低延迟强实时请求，例如必须毫秒级同步返回。
• 单条消息强事务一致性要求极高的核心链路。
• 消息量很小、系统简单，不值得引入 Kafka 运维成本。
• 复杂路由、延迟消息、死信队列等能力要求很强的场景，RocketMQ 或 RabbitMQ 可能更合适。

Kafka 的强项是高吞吐、可回放、可扩展；不是所有消息场景都必须用 Kafka。

6. Kafka 和 RabbitMQ、RocketMQ 全方位对比？

Kafka：

• 吞吐量极高。
• 适合日志、埋点、流处理、大数据场景。
• 消息以 Partition 日志形式持久化，天然支持回放。
• 顺序性按 Partition 保证。
• 功能偏“事件流”，传统消息队列能力需要业务配合。

RabbitMQ：

• 基于 AMQP，功能成熟。
• 路由能力强，支持 exchange、routing key、死信队列等。
• 延迟较低，适合业务消息、任务分发。
• 吞吐量通常不如 Kafka。

RocketMQ：

• 阿里开源，适合电商交易场景。
• 支持事务消息、延迟消息、顺序消息、消息轨迹等。
• 可靠性和业务消息能力强。
• 运维和生态要结合团队经验选择。

简单选择：

• 大数据日志流：Kafka。
• 复杂路由和传统队列：RabbitMQ。
• 电商业务消息、事务消息、延迟消息：RocketMQ。

7. Kafka 中的 Broker、Controller 是什么关系？Controller 的核心作用？

Broker 是 Kafka 集群中的服务节点，负责存储和读写消息。

Controller 是 Kafka 集群中被选出来的一个特殊 Broker 角色。它本身也是 Broker，只是额外承担集群管理职责。

Controller 核心作用：

• 监听 Broker 上下线。
• 负责 Partition Leader 选举。
• 管理分区和副本状态。
• 通知其他 Broker 元数据变化。
• 在 KRaft 架构下参与元数据管理。

一句话：Broker 负责干活，Controller 负责协调集群状态和 leader 变化。

8. Kafka 的 ZooKeeper 架构与 KRaft 架构区别？为什么新版本弃用 ZooKeeper？

早期 Kafka 依赖 ZooKeeper 管理元数据，例如 Broker 注册、Controller 选举、Topic 元数据、分区状态等。

KRaft 是 Kafka 自己实现的基于 Raft 思想的元数据管理机制，用 Kafka 内部的 Controller Quorum 替代 ZooKeeper。

区别：

• ZooKeeper 架构需要额外维护 ZK 集群。
• KRaft 架构不再依赖外部 ZK，架构更简单。
• KRaft 元数据管理在 Kafka 内部完成，扩展性更好。
• KRaft 启动、选主、元数据传播效率更高。

为什么弃用 ZooKeeper？

• 降低部署和运维复杂度。
• 避免 Kafka 和 ZooKeeper 两套系统协作带来的问题。
• 提升元数据管理扩展能力。
• 让 Kafka 架构更加自洽。

面试可以说：新版本 Kafka 的方向是 KRaft，ZooKeeper 架构会逐步退出历史舞台。

二、消息可靠性：丢失、重复、顺序

1. Kafka 消息丢失可能发生在哪些环节？每个环节的丢失原因是什么？

Kafka 消息可能在三个环节丢失：生产者、Broker、消费者。

生产者端：

• 发送后没等 ACK 就认为成功。
• acks=0 或配置太弱。
• 发送失败没有重试。
• 缓冲区满了或程序异常退出。

Broker 端：

• Leader 写入后还没同步到副本就宕机。
• 副本数太少。
• min.insync.replicas 配置不合理。
• 磁盘故障或数据未刷盘。

消费者端：

• 先提交 offset，再处理业务，处理失败后消息就丢了。
• 消费逻辑异常但没有重试。
• 手动提交 offset 提交错了。

所以保证消息不丢，要从 Producer、Broker、Consumer 三端一起做。

2. 如何全方位保证 Kafka 消息不丢？生产者、Broker、消费者各环节如何优化？

生产者端：

• 设置 acks=all，等待所有 ISR 副本确认。
• 开启重试 retries。
• 设置合理的 delivery.timeout.ms、request.timeout.ms。
• 开启幂等生产者 enable.idempotence=true。
• 对发送结果做回调检查。

Broker 端：

• Topic 设置副本数大于 1，常见是 3。
• 设置 min.insync.replicas=2。
• Broker 配合 Producer 的 acks=all。
• 保证磁盘、网络、监控告警可靠。

消费者端：

• 关闭自动提交 offset，处理成功后再手动提交。
• 消费失败要重试或写入死信队列。
• 业务处理和 offset 提交顺序要谨慎。
• 消费逻辑要做好幂等。

最常见组合：acks=all + replication.factor=3 + min.insync.replicas=2 + 手动提交 offset + 消费幂等。

3. Kafka 为什么会出现消息重复消费？常见场景有哪些？

Kafka 默认更容易做到“至少一次”，也就是消息不丢，但可能重复。

常见重复消费场景：

• 消费者处理完业务，还没提交 offset 就宕机。
• offset 提交失败，消费者重启后从旧 offset 继续消费。
• Rebalance 后分区被分配给新消费者，新消费者从已提交 offset 开始消费。
• 生产者发送成功，但 ACK 丢失，生产者重试导致重复写入。
• 网络抖动、超时重试导致重复。

面试重点：消息重复是分布式系统常见现象，业务端必须做幂等。

4. 消息重复消费的解决方案是什么？业务层如何实现幂等性？

解决重复消费的核心是幂等。

常见幂等方案：

• 数据库唯一索引：用消息唯一 id 做唯一键，重复插入直接失败。
• Redis 去重：消费前 setnx messageId，成功才处理。
• 状态机判断：订单只能从待支付到已支付，重复消息不改变状态。
• 业务流水表：处理前先查流水，处理过就跳过。
• 乐观锁版本号：更新时带 version。

生产端可以开启幂等生产者，避免部分重复写入；但消费者端仍然要做业务幂等。

一句话：Kafka 可以减少重复，但不能替代业务幂等。

5. Kafka 如何保证消息的顺序性？分区内有序与全局有序的区别？

Kafka 只保证单个 Partition 内消息有序。

因为一个 Partition 是追加日志，同一个消费者按 offset 顺序消费，所以分区内天然有序。

但多个 Partition 之间是并行写入、并行消费的，不保证全局顺序。

如果要保证某类消息有序，通常做法是让同一个业务 key 的消息进入同一个 Partition。

例如同一个订单号：

key = orderId

Kafka Producer 会根据 key 计算分区，同一个 key 会进入同一个 Partition，从而保证这个订单维度有序。

6. 为什么多分区无法保证全局有序？如何实现全局有序？

多分区无法保证全局有序，是因为每个 Partition 都是独立日志，不同 Partition 的写入和消费是并行的。

比如消息 1 进入 P0，消息 2 进入 P1。P1 的消费者可能先处理完消息 2，所以全局顺序无法保证。

实现全局有序的办法：

• 只使用一个 Partition。
• 只让一个消费者消费。
• 生产端严格按顺序发送。

但这样吞吐量会明显下降。

特殊场景下也可以按业务维度有序，比如订单维度、用户维度，而不是全局有序。实际项目中更推荐“局部有序”，因为全局有序代价太高。

7. 消息乱序的常见原因是什么？如何避免消息乱序？

常见乱序原因：

• 同一业务 key 的消息被发送到不同 Partition。
• Producer 开启重试且允许多个未确认请求并发发送。
• 消费端多线程处理同一个 Partition 的消息。
• Rebalance 后处理逻辑不当。
• 业务异步处理导致后发消息先落库。

避免方式：

• 同一业务 key 固定发送到同一 Partition。
• 需要强顺序时控制 Producer 端并发，例如关注 max.in.flight.requests.per.connection。
• 单个 Partition 内单线程顺序处理。
• 如果要多线程消费，可以按业务 key 分发到同一个工作队列。
• 业务层用状态机或版本号兜底。

顺序性和吞吐量往往是矛盾的，要按业务维度取舍。

三、消息积压与线上排查

1. Kafka 消息积压的常见原因是什么？消费端、生产端、Broker 端分别有哪些？

消息积压指生产速度大于消费速度，导致未消费消息越来越多。

消费端原因：

• 消费者数量不足。
• 消费逻辑太慢，比如调用外部接口、数据库慢 SQL。
• 单条消息处理耗时过长。
• 消费者频繁重启或 Rebalance。
• 消费失败一直重试。

生产端原因：

• 突发流量过大。
• 批量任务集中发送。
• 上游没有限流。

Broker 端原因：

• Broker 磁盘 IO 高。
• 网络带宽瓶颈。
• 分区分布不均。
• 副本同步慢。
• 集群资源不足。

排查时不要只盯消费者，也要看生产速度和 Broker 资源。

2. 线上消息积压的完整排查步骤是什么？如何定位问题根源？

排查步骤：

1. 看消费组 lag，确认哪个 Topic、哪个 Consumer Group 积压。
2. 看积压集中在哪些 Partition，判断是否分区不均。
3. 看生产速率和消费速率，确认是生产突增还是消费变慢。
4. 查看消费者日志，是否有异常、重试、超时。
5. 查看消费耗时，定位慢在业务逻辑、数据库、RPC 还是外部接口。
6. 查看 Consumer 是否频繁 Rebalance。
7. 查看 Broker 磁盘、CPU、网络、请求延迟。
8. 查看下游依赖是否异常，比如数据库连接池满、接口限流。
9. 根据根因选择扩容、限流、优化 SQL、批量消费或临时跳过异常消息。

一句话：先定位 Topic 和消费组，再看 lag 分布，最后从消费端、生产端、Broker、下游依赖逐层排查。

3. 解决消息积压的最优方案有哪些？不同场景如何选择？

不同原因对应不同方案。

如果是消费者能力不足：

• 增加消费者实例，但不能超过分区数。
• 提高单条消息处理效率。
• 批量拉取、批量写库。
• 优化数据库和外部接口。

如果是分区数不足：

• 增加 Topic 分区数。
• 配合增加消费者数量。
• 注意增加分区可能影响 key 顺序性。

如果是某些消息处理失败：

• 加重试次数上限。
• 异常消息进入死信队列。
• 避免一条坏消息阻塞整个分区。

如果是突发流量：

• 上游限流。
• 临时扩容消费者。
• 降级非核心逻辑。

如果是 Broker 瓶颈：

• 扩容 Broker。
• 均衡 Partition。
• 优化磁盘和网络。
• 调整副本同步和刷盘相关配置。

最优方案不是固定的，关键是先定位瓶颈。

4. 增加消费者数量能解决积压吗？为什么不能超过分区数量？

增加消费者数量可以提升消费能力，但前提是 Topic 有足够的分区。

在同一个消费组内，一个 Partition 同一时刻只能被一个消费者消费。这样才能保证分区内顺序。

如果一个 Topic 有 6 个 Partition，那么同一个消费组最多 6 个消费者能并行消费。第 7 个消费者会闲置。

所以消费者数量超过分区数不会继续提升吞吐。

要提升并行度，一般需要：

• 增加分区数。
• 增加消费者数。
• 优化单消费者处理速度。

5. 分区数量的设置原则是什么？过多或过少会有什么问题？

分区数量决定了 Kafka 的并行能力。

设置原则：

• 根据目标吞吐量估算。
• 根据消费者并行度估算。
• 考虑 Broker 数量和副本数。
• 给未来增长留一定余量。
• 有顺序性要求时不能盲目增加分区。

分区太少的问题：

• 并行度不足。
• 消费者扩容受限。
• 容易积压。

分区太多的问题：

• 文件句柄和内存占用增加。
• Controller 管理压力变大。
• Rebalance 成本变高。
• Leader 选举和副本同步开销增加。
• 单个 Broker 上小文件和日志段更多。

面试可以说：分区数不是越多越好，要在吞吐、顺序性和运维成本之间平衡。

6. 如何避免消息积压？日常运维需要注意哪些点？

避免积压要靠日常监控和容量规划。

需要关注：

• Consumer Lag 监控和告警。
• 生产速率和消费速率。
• Broker 磁盘使用率。
• Broker 网络、CPU、请求延迟。
• 消费者异常率、重试次数、处理耗时。
• Rebalance 频率。
• 下游数据库、接口、缓存状态。

日常优化：

• Topic 分区数提前规划。
• 消费者处理逻辑保持轻量。
• 慢操作异步化或批量化。
• 异常消息进入死信队列。
• 上游突发流量做好限流。
• 核心 Topic 做容量压测。

真正线上稳定的 Kafka，不是只靠参数，而是靠监控、告警、限流、扩容和降级一起兜底。

四、面试回答小抄

• Kafka 是分布式事件流平台，核心价值是高吞吐、可持久化、可回放、可扩展。
• Topic 是逻辑主题，Partition 是并行和存储单位，Replica 是高可用副本。
• Kafka 高吞吐靠顺序写、Page Cache、零拷贝、批量压缩、分区并行。
• Kafka 只保证单 Partition 有序，不保证多 Partition 全局有序。
• 消息不丢要从 Producer、Broker、Consumer 三端一起保证。
• 消息重复很常见，业务层必须做幂等。
• 全局有序通常只能单分区，吞吐会下降，实际更推荐业务维度有序。
• 消息积压先看 lag，再看生产速率、消费速率、分区分布和下游依赖。
• 同一消费组内消费者数量超过分区数不会提升消费能力。
• KRaft 是 Kafka 去 ZooKeeper 的新架构方向，降低运维复杂度。

总结

Kafka 面试题可以按四条主线理解：

• 架构：Producer、Consumer、Broker、Topic、Partition、Replica、Controller。
• 性能：顺序写、Page Cache、零拷贝、批量、压缩、分区并行。
• 可靠性：不丢、不重、幂等、顺序性，分别从生产者、Broker、消费者看。
• 运维：消息积压、分区规划、消费者扩容、Broker 资源瓶颈。

面试回答 Kafka 时，不要只背概念。先讲清楚“Kafka 解决什么问题”，再讲“为什么能做到高吞吐”，最后补上“消息丢失、重复、顺序和积压怎么处理”，整体就会很完整。