Kafka 面试题是这个领域最容易被面试官连环追问的方向尤其是“消息可靠性怎么保证”“Kafka 为什么快”“怎么保证顺序”“重复消费怎么解决”这几种问题几乎每个岗位都会问。与其零散刷几十道题不如直接按 16 个高频问题把 Kafka 的架构、存储、副本、消费组、事务、性能优化全部串起来。这篇文章就把这 16 个问题拆成原理和答案同时给出本地部署、命令行验证、可视化工具和性能测试的完整流程适合准备面试的 Java 后端、大数据工程师也适合想系统补 Kafka 基础的技术同学。文章会先给你一张能力速览表然后按照基础架构、副本可靠性、消费端、高级特性四个维度展开 16 问每个问题都有面试官想问什么、怎么答、容易踩的坑。最后会补上集群部署、可视化工具、性能观察和故障排查把这些内容跑一遍你对 Kafka 的掌握就不是背题而是真正能落地。1. 核心能力速览能力项说明面试主题Kafka 原理、架构、可靠性、消费端、事务、性能优化覆盖问题16 个高频面试问题分 4 个模块配套实操Kafka 本地部署、Docker 部署、命令行生产消费、性能压测工具支持命令行工具、可视化工具、Java API 方式适合人群Java 后端、大数据开发、中间件维护、准备 Kafka 面试的工程师知识点权重消息可靠性、消息顺序、消费端 Offset、消息积压、高可用环境要求JDK 82 核 4G 以上机器即可跑单机版是否支持批量任务支持自带 producer/consumer 性能测试脚本是否支持接口服务支持Producer/Consumer API 和 AdminClient API面试价值覆盖绝大多数 Kafka 面试场景重点在理解后的表达Kafka 面试和普通 CRUD 面试不一样面试官不会只问“Kafka 是什么”而是会围绕“丢消息、重复消费、消息积压、顺序性、事务”这些问题追问到底。所以这篇文章不是罗列概念而是把概念、配置、代码验证放到一起讲。2. 适用场景与使用边界Kafka 适合高吞吐、低延时的数据管道场景比如日志收集、用户行为埋点、系统监控数据、事件驱动架构、流式处理。它靠分区和副本实现了水平扩展和故障恢复所以在大数据领域几乎是标配。但它不是万能消息队列。如果只是简单的点对点任务队列比如订单超时关单、发邮件通知这种低频小消息用 Kafka 反而偏重运维成本和消息语义都比 RocketMQ、RabbitMQ 更复杂。面试时如果被问到“MQ 选型”要能说清楚这个边界。使用 Kafka 也需要注意几个边界。第一分区内有序但跨分区不保证全局有序除非只用一个分区这会牺牲吞吐第二消费端要实现幂等因为 At Least Once 语义下重复消费是常态第三消息积压后不能盲目增加消费者因为分区数限制了消费并行度。面试的时候能主动提这些边界会显得你对 Kafka 有真正的理解。3. Kafka 本地部署与集群环境准备不要光背理论先把 Kafka 跑起来你才能理解 Leader、ISR、Offset、Consumer Group 这些概念。下面给出一套通用的部署方式Windows、Linux 和 Docker 都能覆盖。3.1 下载与依赖准备Kafka 依赖 JDK。从 3.x 开始Kafka 支持 KRaft 模式不再强制依赖 ZooKeeper但很多生产环境和面试题仍然会提到 ZooKeeper所以这里两种模式都说明。# 检查 JDKKafka 2.x 通常要求 JDK 83.x 支持 JDK 8/11 java -version # 下载 Kafka这里以 tar.gz 示例版本号按官方实际版本替换 wget https://downloads.apache.org/kafka/3.7.0/kafka_2.13-3.7.0.tgz tar -zxvf kafka_2.13-3.7.0.tgz cd kafka_2.13-3.7.0启动前先确认端口。默认端口是9092如果本机已被占用需要修改config/server.properties里的listeners。3.2 单机启动与验证Kafka 单机版适合本地学习。使用 KRaft 模式时先格式化存储目录再启动服务即可。# 生成 cluster id并格式化存储目录 KAFKA_CLUSTER_ID$(bin/kafka-storage.sh random-uuid) bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties # 启动 Kafka bin/kafka-server-start.sh config/kraft/server.properties如果是传统的 ZooKeeper 模式需要先启动 ZooKeeper再启动 Kafka Broker。# 先启动 ZooKeeper bin/zookeeper-server-start.sh config/zookeeper.properties # 再启动 Kafka Broker bin/kafka-server-start.sh config/server.properties启动后看到started (kafka.server.KafkaRaftServer)或started (kafka.server.KafkaServer)就说明服务正常。3.3 Docker 部署方式Docker 方式更快适合在资源有限的环境快速验证。下面是一个常见的 Kafka 可视化工具的docker-compose.yml示例。version: 3.8 services: kafka: image: bitnami/kafka:latest container_name: kafka ports: - 9092:9092 environment: - KAFKA_CFG_NODE_ID1 - KAFKA_CFG_PROCESS_ROLEScontroller,broker - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS1kafka:9093 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://localhost:9092 - KAFKA_CFG_CONTROLLER_LISTENER_NAMESCONTROLLER - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAPCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT volumes: - kafka_data:/bitnami/kafka volumes: kafka_data:启动命令docker-compose up -d docker-compose ps注意不同镜像的环境变量和配置方式不一样bitnami/kafka和apache/kafka的配置项有差异实际使用时以镜像文档为准。Docker 部署主要是验证功能和 API生产环境通常还是建议独立部署。3.4 Windows 部署说明Windows 下安装 Kafka 只需要把 tar.gz 解压到本地然后进入bin/windows目录使用.bat脚本。比如cd C:\kafka\bin\windows zookeeper-server-start.bat ..\..\config\zookeeper.properties kafka-server-start.bat ..\..\config\server.propertiesWindows 部署容易出现端口占用和路径中文问题建议目录不要带中文端口先用默认避免踩坑。4. Kafka 核心原理 16 问基础架构与存储这一部分进入正题。每道题都是面试官的高频问题答案要按“结论 原理 关键点”组织。4.1 第一问Kafka 是什么核心角色有哪些Kafka 是一个分布式消息队列本质是一个分布式的持久化日志系统。它的核心角色包括 Producer、Consumer、Broker、Topic、Partition、Offset、Consumer Group。Producer消息生产者负责把消息发送到 Topic。Consumer消息消费者从 Topic 拉取消息。Broker一台 Kafka 服务节点一个集群由多个 Broker 组成。Topic消息的逻辑分类对应数据库里的表。PartitionTopic 物理上的分区是消息并行读写的最小单位。Offset消息在分区内的位置类似数组下标。Consumer Group一组协同消费 Topic 的消费者同一个分区的消息只会被组内一个消费者消费。面试官追问时你要能说出 Kafka 相比传统 MQ 的关键差异Kafka 不是 AMQP 协议而是自定义的二进制协议消费时使用 pull 模式而不是 push 模式消息写入磁盘而不是内存因此可以支持海量数据回溯。4.2 第二问Kafka 为什么能支撑高吞吐这是必考题。核心原因有四个。第一顺序追加写磁盘。Kafka 每个分区对应一个目录消息是 append 到日志文件末尾的顺序写磁盘比随机写快几个数量级。第二Page Cache 和操作系统零拷贝。Kafka 读写依赖操作系统 Page Cache数据先写入缓存系统异步刷盘消费端通过sendfile系统调用直接从 Page Cache 发到网卡避免内核态和用户态拷贝。第三批量处理。Producer 可以按批次发送消息batch.size和linger.ms控制批量大小和等待时间减少网络请求次数。第四分区并行。一个 Topic 拆成多个 PartitionProducer 可以并行写Consumer 可以并行读。回答时可以补充一点Kafka 的“快”不是靠内存堆积而是靠磁盘顺序读写和零拷贝。这样能让面试官知道你不是只会背术语。4.3 第三问Topic 和 Partition 有什么关系分区策略怎么选Topic 是逻辑概念Partition 是物理概念。一个 Topic 可以有多个 Partition每个 Partition 是一个有序日志同一份数据根据 key 路由到不同分区。Partition 的数量决定了并行度但也直接影响文件句柄数量、Leader 选举时间和消息顺序性。分区策略常见的有三种指定分区Producer 直接指定 partition精确控制。key 路由没有指定分区时根据 key 的 hash 取模分区数相同 key 的消息会进入同一分区。轮询没有 key 时使用 sticky partition 策略尽量把消息聚合到一个分区减少请求次数。面试中如果被问到“如何让同一用户的消息有序”答案通常是“用用户 ID 作为 key让相同 key 进入同一分区”。但要补充前提分区数不变时路由结果才稳定如果分区扩容旧消息仍然在旧分区新消息可能去新分区全局顺序无法保持。4.4 第四问Kafka 日志存储结构是怎样的每个 Partition 在磁盘上是一个目录目录名是topic-partition。日志文件按 segment 分段存储每个 segment 由.log、.index、.timeindex等文件组成。.log真正的消息数据。.index稀疏索引记录 offset 到物理位置的映射。.timeindex时间索引用于按时间戳查找消息。消息写入时先写当前活跃 segment当 segment 大小超过log.segment.bytes默认 1GB或者时间超过log.roll.hours时会滚动生成新的 segment。因为索引是稀疏的查找时先通过二分找到最近索引项再在日志文件里顺序扫描这也是 Kafka 能保持高性能的原因之一。日志清理策略有两种delete按时间或大小删旧数据compact按 key 保留最新值。面试可以提一下 compact 策略常用于存储用户最新状态这种场景。5. Kafka 核心原理 16 问副本、ISR 与可靠性5.1 第五问副本机制是怎么工作的Leader 和 Follower 如何同步Kafka 每个分区可以有多个副本副本分为 Leader 和 Follower。Producer 只往 Leader 写入Consumer 也只从 Leader 拉取Follower 主动从 Leader 拉取数据进行同步当 Leader 挂了Controller 会从 ISR 里选一个新的 Leader。这里有一个容易被忽略的点Kafka 的副本同步是 Follower 主动 pull不是 Leader push。Follower 会不断发送 Fetch 请求拉取 Leader 上的数据并更新自己的日志。副本数通过replication.factor配置生产环境一般设置 3至少也要 2。副本数越多容错性越强但磁盘和网络开销也越大。5.2 第六问ISR 是什么为什么 ISR 对可靠性很重要ISRIn-Sync Replicas是与 Leader 保持同步的副本集合。Kafka 不会让所有 Follower 都参与 Leader 选举只有 ISR 里的副本才具备候选资格。Follower 如果长时间没有向 Leader 请求同步数据超过replica.lag.time.max.ms默认 30 秒就会被踢出 ISR。ISR 收缩后如果 Leader 挂了Kafka 只能在 ISR 内选新 Leader。如果把unclean.leader.election.enable设为 true也可以允许不在 ISR 里的副本成为 Leader但这时会丢数据所以生产环境建议设置为 false。min.insync.replicas和acksall配合使用可以保证至少指定数量的副本确认写入。比如副本数为 3min.insync.replicas2那么至少 2 个副本同步成功才返回成功这就是“消息不丢失”的硬性保障。5.3 第七问HW 和 LEO 是什么意思为什么和消息丢失有关LEOLog End Offset是每个副本日志最后一条消息的 offset 加 1HWHigh Watermark是 ISR 中所有副本都已经同步到的 offsetConsumer 只能消费 HW 之前的消息。Leader 收到消息后本地 LEO 增加Follower 拉取并写入后Follower 的 LEO 增加当所有 ISR 副本的 LEO 都大于等于某个 offset 时Leader 更新 HW此时这条消息才对 Consumer 可见。出现故障时Follower 会根据 HW 进行日志截断截断到 HW 位置。这种机制在旧版本中可能导致消息丢失或重复尤其在 leader 切换时。Kafka 后来引入了基于 epoch 的 leader 选举机制用来避免“僵尸 Leader”带来的不一致。面试被问“Kafka 怎么保证不丢消息”时可以延伸到这一层会明显加分。5.4 第八问acks 参数怎么配置才靠谱acks是 Producer 端最重要的可靠性参数有三个值acks0发送后不等确认吞吐最高但可能丢消息。acks1Leader 写入成功就返回成功默认值可靠性中等Leader 挂时会丢数据。acksallISR 所有副本都同步成功才返回成功可靠性最高延迟也会更高。生产环境如果业务允许建议配置acksall retries3 enable.idempotencetrue max.in.flight.requests.per.connection5enable.idempotencetrue会自动把acks变成all同时配合幂等机制解决重复消息问题。这里要注意开启幂等后max.in.flight.requests.per.connection可以大于 1但如果是想配合事务或绝对顺序通常需要把max.in.flight.requests.per.connection设为 1。6. Kafka 核心原理 16 问消费组、Offset 与顺序性6.1 第九问Consumer Group 是如何工作的分区分配策略有哪些Consumer Group 是 Kafka 实现集群消费的手段。一个 Group 由多个 Consumer 组成同一个 Group 内的消费者共同消费订阅 Topic 的全部消息但一个 Partition 只会分配给一个消费者。这样做的好处是一个消费者挂掉后其他消费者可以接管它的分区实现故障转移。分区分配策略有三种Range按 Topic 逐个分配每个 Topic 的连续分区分配给连续的消费者可能造成分配不均。RoundRobin所有 Topic 的分区统一轮询分配比 Range 更均匀。Sticky在保持上次分配尽量不变的基础上做重新平衡减少分区迁移。面试被问“消费组内消费者数大于分区数会怎样”答案是部分消费者会空闲因为一个分区只能被一个消费者消费所以消费并行度上限就是分区数。6.2 第十问Offset 提交机制是什么自动提交和手动提交怎么选Offset 表示消费者消费到分区的位置。Consumer 处理完消息后需要提交 Offset才能让 Group 知道从哪里继续消费。如果 Offset 提交失败或提交时机不对就可能出现重复消费或消息丢失。自动提交默认开启enable.auto.committrue提交间隔由auto.commit.interval.ms默认 5000ms控制。自动提交的问题在于如果消费者在自动提交前崩溃重启后会从上次提交的 Offset 开始消费中间处理完但没提交的消息会再消费一次。手动提交更可控。手动提交分同步提交commitSync和异步提交commitAsync。同步提交会阻塞直到提交成功异步提交不阻塞但可能失败。生产环境通常使用异步提交并在回调中记录失败日志或在关闭时补充一次同步提交。6.3 第十一问Kafka 如何保证消息顺序全局顺序可以实现吗Kafka 只能保证分区内消息有序。因为同一个分区里的消息是 append 写入的Follower 同步时也按相同顺序写入所以只要 Producer 写入时按顺序发送消费者按分区消费就能保证有序。跨分区没有全局顺序。如果要全局有序只能让 Topic 只有一个 Partition或者让所有消息都路由到同一个分区。这样做的代价是吞吐量大幅下降实际项目里基本不会全局有序而是按业务 key 保证局部有序。消费端想保证处理顺序不能开多线程乱序消费。如果同一个 key 的消息进入同一个分区消费线程也必须保证这个分区内的消息是按顺序处理的否则同样会乱序。6.4 第十二问重复消费是怎么产生的消费端如何幂等重复消费的根本原因是“处理成功但提交 Offset 失败”。比如消费者拉取一批消息处理完准备提交 Offset 时进程崩溃重启后 Group 会从上次提交的位置开始拉这批消息就会被再次消费。重复消费的解决方案是消费端幂等。最常用的做法是在消息里带上全局唯一的业务 ID消费时先去 Redis 或数据库查一下这个 ID 是否处理过处理过就直接跳过或者用数据库唯一约束来兜底让重复消息插入失败但不抛异常。面试时不要只说“用 Redis 去重”要能说出根据业务主键做唯一性约束、状态机更新时校验前置状态这些更工程化的方案。7. Kafka 核心原理 16 问事务、幂等与消息不丢失7.1 第十三问Kafka 幂等生产者和事务是什么关系幂等生产者是 Kafka 0.11 引入的能力开启enable.idempotencetrue后Producer 会给每条消息加上序列号Broker 会根据producerId, sequence去重避免因为重试导致同一条消息写入多次。但幂等只能保证单个 Producer 会话内的单分区无重复不能保证原子写多个分区。事务机制则是把多个分区消息的写入变成一个原子操作要么全部成功要么全部失败。事务 API 的使用步骤一般是这样producer.initTransactions(); try { producer.beginTransaction(); producer.send(new ProducerRecord(topic-a, key, value)); producer.send(new ProducerRecord(topic-b, key, value)); producer.commitTransaction(); } catch (Exception e) { producer.abortTransaction(); }面试时只要说明幂等解决“单分区重复”事务解决“跨分区原子性”就已经抓住了核心。7.2 第十四问Kafka 如何保证消息不丢失三端配置分别是什么消息从生产到消费经过三个阶段Producer 发送、Broker 存储、Consumer 消费。每个阶段都可能丢消息面试要能分别给出方案。生产端使用acksall等待所有副本同步成功。开启retries失败自动重试注意设置合理的retry.backoff.ms。开启幂等enable.idempotencetrue避免重试造成重复消息。Broker 端设置replication.factor3。设置min.insync.replicas2。设置unclean.leader.election.enablefalse避免不同步副本成为 Leader。log.flush.interval.messages和log.flush.interval.ms控制刷盘频率生产环境建议默认即可不要频繁强制刷盘否则吞吐下降。消费端关闭自动提交enable.auto.commitfalse。先处理业务再提交 Offset业务失败就不提交。消费逻辑做好幂等因为 Kafka 的投递语义整体是 At Least Once重复无法完全避免。这三段式回答是面试的标准模板能覆盖大部分“如何保证消息不丢失”的追问。7.3 第十五问消息积压怎么解决为什么不能无限增加消费者消息积压的本质是消费速度小于生产速度。先要定位是生产太快、消费代码性能差还是下游依赖阻塞。处理方式包括如果 Topic 分区数不够可以增加分区数同时增加消费者数量但注意分区扩容后消息分布会变化只影响新消息。优化消费逻辑比如批量消费max.poll.records调大减少网络开销。检查消费线程模型避免单线程消费导致瓶颈。临时紧急处理时可以把消息转发到一个新的 Topic用更多的消费者处理原 Topic 继续正常消费新消息。不能无限增加消费者的原因是一个 Partition 只能被同组一个消费者消费消费者数超过分区数后多出来的消费者不会分配到任何分区。所以要先提高分区数再增加消费者。面试官还可能追问max.poll.interval.ms如果消费者处理一条消息时间超过这个时间就可能触发 rebalance这是消息积压时经常遇到的现象。7.4 第十六问Kafka 高可用如何实现Broker 宕机后会发生什么Kafka 的高可用建立在副本机制和 Controller 协调之上。每个 Partition 有多个副本副本分散在不同 Broker 上单个 Broker 宕机不会导致整个 Topic 不可用。Broker 宕机后Controller 会感知到 Broker 下线然后从该 Broker 上所有 Leader 分区的 ISR 中挑选新的 Leader。如果宕机的 Broker 不是 ControllerController 本身不切换如果是 Controller 节点挂了其他 Broker 会重新竞选 Controller。配置层面集群中每个 Broker 都应该有一个唯一的broker.id所有 Broker 使用相同的zookeeper.connect或 KRaft 控制器地址。生产环境通常用 3 个以上 Broker副本数 3min.insync.replicas2这样单节点宕机不会影响读写。面试时可以补充Kafka 的高可用不代表数据不丢如果acks1Leader 宕机后未同步的数据依然会丢失所以高可用和可靠性是两个维度的配置。8. 命令行验证与可视化工具理论讲完了还要动手验证。下面这条链路可以帮你把前面的概念串起来创建 Topic、生产数据、消费数据、查看 Group Offset。# 创建名为 test-topic3 个分区、2 个副本的 Topic bin/kafka-topics.sh --bootstrap-server localhost:9092 \ --create --topic test-topic --partitions 3 --replication-factor 2 # 查看 Topic 列表 bin/kafka-topics.sh --bootstrap-server localhost:9092 --list # 控制台生产消息输入内容后回车发送 bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic test-topic # 控制台消费消息从最开始消费 bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic test-topic --from-beginning # 查看消费者组和 Offset bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --describe --group test-group如果想看更直观的界面可以使用 Kafka 可视化工具。常见的开源可视化工具包括 Kafka UI、Kafka Map、Offset Explorer 等它们通常支持查看 Broker、Topic、Partition、Consumer Group、消息内容。下面是一个基于 Kafka UI 的 Docker Compose 补充示例kafka-ui: image: provectuslabs/kafka-ui:latest container_name: kafka-ui ports: - 8080:8080 environment: - KAFKA_CLUSTERS_0_NAMElocal - KAFKA_CLUSTERS_0_BOOTSTRAPSERVERSkafka:9092 depends_on: - kafka启动后访问http://localhost:8080就能看到集群信息和 Topic 详情。可视化工具虽然不影响面试但能帮你快速观察消息和 Offset 变化。9. 资源占用与性能观察Kafka 性能测试是面试加分项也是工作中排查问题的手段。Kafka 自带两个性能测试脚本kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。# 生产性能测试每秒发送多少条多少 MB/s bin/kafka-producer-perf-test.sh \ --topic test-topic \ --num-records 100000 \ --record-size 1000 \ --throughput -1 \ --producer-props bootstrap.serverslocalhost:9092 key.serializerorg.apache.kafka.common.serialization.StringSerializer value.serializerorg.apache.kafka.common.serialization.StringSerializer性能观察要看几个方面吞吐指标records/sec和MB/sec用来判断当前配置是否达到预期。延迟指标latency avg、latency max观察acksall和acks1的差异。资源占用CPU、内存、磁盘 IO、网络流量。Kafka 是磁盘和网络密集型应用磁盘 IO 过高或 GC 频繁都会影响延迟。分区数影响分区越多并行度越高但每个分区都有 Leader 和 Follower 的 IO分区过多会导致文件句柄和内存压力增大。如果你想观察 JVM 堆内存和 GC可以开启 JMX 或用 JVM 自带工具。生产环境建议用 Prometheus Grafana 采集 Kafka 指标面试时提到这个监控组合会显得更懂运维。10. 常见问题与排查方法问题现象可能原因排查方式解决方案客户端连不上 Kafkalisteners 配置错误、端口被防火墙拦截检查listeners、advertised.listeners、telnet 端口修正 listeners确认 broker 地址可达生产者发送超时网络抖动、acksall 但副本不足查看 producer 日志和 broker 日志调整 retries、timeout检查副本状态消费者拉不到消息消费组 Offset 已到末尾、订阅 Topic 错误查看 consumer group describe 和消息生产情况重置 Offset 或重新验证订阅重复消费自动提交 Offset 过早、处理超时触发 rebalance检查消费日志和提交时机关闭自动提交业务处理完再提交做幂等消息积压分区数不足、消费者处理慢、poll 间隔超时看 consumer lag 和消费线程状态增大批量、加分区加消费者、优化处理逻辑Leader 副本不足某个 Broker 宕机或 ISR 缩小查看kafka-topics.sh --describe恢复 Broker检查min.insync.replicas配置分区扩容后数据倾斜旧消息分布不均、key 路由变化检查分区 leader 分布生产环境提前规划分区数尽量减少扩容磁盘写满日志保留时间过长、消息量大查看磁盘使用率和log.retention配置调整 retention、扩大磁盘、清理旧数据排查问题时要先分清是生产端、Broker 端还是消费端的问题。最简单的办法是分别看三端日志Producer 日志、Broker 的server.log、Consumer 日志。能快速定位到是哪一端面试官会认为你有真实故障处理经验。11. 总结与下一步这 16 个问题看起来多其实都在围绕一条主线Kafka 通过分区和副本实现高吞吐和可靠性但分布式系统没有银弹可靠性靠配置约束顺序性靠分区约束重复消费靠幂等兜底。只要把这条主线说清楚面试官怎么追问你都能接住。建议你按下面的顺序去准备先把 Kafka 本地跑起来用命令行创建 Topic、生产消费消息观察 Offset然后对照文章里的 16 问把每道题用自己话讲一遍最后可以自己搭一个 3 节点集群测试一下 Broker 宕机后 Leader 切换体验一次副本机制的实际效果。最容易踩的坑是背答案。面试官问“Kafka 怎么保证不丢消息”如果你只会背“acksall”他就继续问“副本同步落后怎么办”“ISR 什么时候缩”这时候只有真正理解原理才能答上来。下一步可以继续看源码里消息追加、副本拉取、Consumer 协调器的实现也可以做一轮 Producer 参数压测对比用数据验证吞吐和可靠性的权衡。把这几轮做完Kafka 面试题就不需要靠刷而是真正变成你自己的技术积累。建议收藏备用。下次再看到“Kafka 夺命连环问”你已经不是背题的人而是能给别人讲清楚的人。