作为一个在数据链路里摸爬滚打了多年的后端开发我面试过不少人也被面试官按在地上摩擦过不少次。Kafka 几乎是大数据生态和后端架构里绕不开的一道坎无论是消息中间件选型、实时数仓建设还是面试时被追着问到底懂不懂原理它总会出现。但说句实话大多数人对 Kafka 的认知停留在能发消息能收消息的使用层面。缓存满了怎么办分区数怎么定为什么明明配置了副本数据还能丢消费者组一扩容就 rebalancerebalance 期间整个消费停摆这背后到底是什么机制在起作用这些问题如果答不上来面试基本就凉了一半。所以这篇我打算彻底掰开揉碎把 Kafka 从生产到消费的完整链路、存储设计、副本同步、消费组机制、消息可靠性这几个最核心的模块讲透顺带把面试里出现频率极高的考点和排查思路一起串进去。内容会偏原理和实战结合不适合只想要三分钟上手的人适合真正想把这套东西吃进脑子里的开发者。1. 先搞懂整体架构一条消息从生产到消费的完整旅程Kafka 的架构名词很多Broker、Producer、Consumer、Topic、Partition、Replica、ZooKeeper现在 KRaft……第一次接触的人很容易被绕晕。其实你用快递系统的思路去理解一下就通了。1.1 核心角色的协作关系Broker就是一台台快递中转站负责存储和转发消息。一个 Kafka 集群由多个 Broker 组成每个 Broker 就是一个独立的进程。Topic消息的类别相当于不同的物流线路比如订单消息走一条线用户行为日志走另一条线。Partition同一个 Topic 又被拆成多个分区相当于一条物流线路被切成多个并行的车道这是 Kafka 并行度的根本来源。Replica每个分区又有若干个副本副本之间是一主多从的关系负责保证数据的冗余和可用性。Producer消息的生产者相当于寄件人。Consumer / Consumer Group消息的消费者相当于收件人。同一个消费组里的消费者共同分担一个 Topic 下所有分区的消费任务组内是竞争关系不同消费组之间是订阅关系都能拿到全量消息。这套模型里最简单的理解方式是Topic 是逻辑概念Partition 是物理概念。消息真正落盘存储的最小粒度是分区而不是 Topic。消费的并行度也受限于分区数分区数越多理论上能同时消费的消费者就越多。1.2 一条消息从诞生到被消费的流转路径我习惯把 Kafka 的消息流转画成一条流水线每个环节都能单独拆开排查问题Producer 根据 key 做分区路由决定这条消息进入哪个分区。Producer 将消息按批次发送到对应分区的 Leader 副本所在的 Broker。Broker 收到消息后写入手头的 Page Cache然后落盘追加到该分区的日志分段文件尾部。Follower 副本从 Leader 拉取消息写入自己的日志并定时向 Leader 反馈同步进度。消费者通过 poll 模式主动向 Broker 拉取消息而不是 Broker 推送。消费者处理完消息后提交 offset记录自己消费到了哪个位置。如果消费者宕机或新消费者加入触发 Rebalance重新分配分区归属。这 7 步里每一步都有对应的坑。比如第 2 步的批次如果设置不当消息延迟会高得离谱第 6 步的 offset 提交时机不对就会出现重复消费或者消息丢失第 7 步的 Rebalance 机制如果没吃透线上消费者组随便一改就会导致全组停止消费那是真正的生产事故级别问题。下面几个章节我会把最关键的环节逐个拆开讲。2. 存储层为什么这么快日志分段、顺序写与页缓存Kafka 之所以吞吐量能做到百万级每秒很多人以为是网络模型好、NIO 用得好但这只是表面。它的内核在存储层没有这套存储设计任何网络优化都是空中楼阁。2.1 分区不只是文件夹日志分段与稀疏索引每个 Partition 在磁盘上对应一个目录目录名格式是topic-分区号。消息不是零散地一个个文件存放而是被追加写入到活跃分段文件里。当这个分段文件大小达到阈值默认 1GB或者时间到了就滚动生成一个新的分段文件旧文件变成只读 Segment。每个 Segment 由三个关键文件组成.log文件消息的原始数据就是纯粹的字节追加。.index文件稀疏索引记录消息的相对偏移量与物理磁盘位置的映射。.timeindex文件按时间戳建立的索引方便按时间维度定位消息。为什么用稀疏索引而不是每条消息都建立索引因为 Kafka 是顺序写盘消息在文件里本身就是有序排列的。查找某个 offset 时先通过二分查找定位到大概的索引项再在 .log 文件里顺序扫描一小段就能找到目标消息。用稀疏的空间代价换取了极快的查找速度同时减少了内存占用。我见过不少人在面试时被问Kafka 为什么要用顺序写一个典型的错误回答是因为磁盘只有顺序写才快。这个回答不全面顺序写快的前提是操作系统对文件系统的顺序写做了大量优化比如预读、批量调度再加上 Kafka 本身把随机写转换成了顺序追加两者叠加之后磁盘的顺序写性能可以接近内存的随机写性能。关键不在于磁盘本身而在于你如何利用磁盘的特性。2.2 页缓存与零拷贝Kafka 在写入时并不是每条消息都直接刷到磁盘而是先写入操作系统页缓存由操作系统统一决定何时将脏页刷入磁盘。这样做有几个好处一是写入路径短消息到达 Broker 后只需要复制到页缓存就算完成不需要等待磁盘 I/O 完成。二是天然具备缓存能力消费者读取最近写入的消息时大概率直接命中页缓存连磁盘都不用碰。三是在 Broker 进程重启的情况下只要操作系统还在页缓存中的内容依然有效Kafka 不需要自己做缓存重建。消费者读取消息时Kafka 做了零拷贝优化。传统的数据读取需要经过磁盘 - 内核缓冲区 - 用户空间 - Socket 缓冲区 - 网卡四次拷贝而 Kafka 使用 sendfile 系统调用数据直接从内核缓冲区到网卡省掉了用户空间和 Socket 缓冲区的拷贝配合 DMA 技术实现了几乎不占用 CPU 的高速传输。这里有个很容易踩的坑很多人以为把 log.flush.interval.messages 设置得越小越安全比如每条消息都强制刷盘。这个参数如果设置过小会造成极其严重的性能问题因为强制刷盘会破坏顺序写的批量效应。Kafka 的默认设计理念是数据安全交给副本机制而不是交给单机刷盘理解了这一点就不会乱调参数。3. 副本机制与一致性ISR、HW、LEO 里藏着的高频考点Kafka 的副本机制是面试重灾区ISR 的全称是 In-Sync Replicas同步中的副本集合HW 是 High Watermark高水位LEO 是 Log End Offset日志末端偏移量。这三个名词单独拿出来都认识但组合在一起就能问出花来。3.1 ISR 是什么为什么需要它每个分区有多个副本其中一个是 Leader负责读写请求其余是 Follower负责从 Leader 同步数据。如果每个 Follower 都必须确认我同步成功了Leader 才返回生产者写入成功那延迟会非常高如果完全不等 Follower 同步Leader 一宕机数据就丢。ISR 就是在这两者之间取一个平衡。ISR 是一个动态维护的副本集合只有满足与 Leader 的同步进度差不超过阈值的副本才会留在 ISR 里。当某个 Follower 同步滞后超过阈值由 replica.lag.time.max.ms 控制默认 30 秒它会被踢出 ISR。生产者设置 acksall 时只需要 ISR 里的副本确认写入不需要等待所有副本确认。Kafka 2.x 之后移除了基于消息条数的 lag 判断只保留基于时间的滞后判断。这个变化很值得注意以前落后 N 条就踢出 ISR的机制在高吞吐场景下容易出现抖动误判比如消费慢的 Follower 只是暂时跟不上但马上就要追上了却被误踢出去。改成时间维度后只要副本在 30 秒内有过同步动作就认为它还活着、还在努力追这种容错性合理得多。3.2 LEO 与 HW 的推进过程LEO日志末端偏移量表示该副本下一条待写入消息的位置。HW高水位表示消费者能看到的最高消息偏移量。只有小于 HW 的消息才是已提交的消息消费者才能读取。HW 的更新规则是Leader 的 HW 取 ISR 中所有副本 LEO 的最小值。什么意思就是 Leader 只会把那些已经在所有 ISR 副本中都存在了的消息标记为可消费。如果有一个副本还没同步到某条消息这条消息即便在 Leader 上已经存在也不能被消费者看到。这里有一个经典的面试连环问如果一个 Follower 宕机后恢复它会做什么答案是它会先截断自己的日志到 HW 位置然后从 Leader 重新拉取 HW 之后的数据。因为宕机期间它可能写入了不少 Leader 没有的数据比如它曾短暂当过 Leader这些数据在故障恢复时一律视为无效数据必须截断。还有一个更刁钻的问题消费者有可能读到 HW 以下的消息然后这些消息又消失了会的。这就是 Kafka 的数据丢失场景之一具体发生在 ISR 里只有 Leader 一个副本的时候。假设 acksall只有 Leader 一个 ISR消息写入成功返回给生产者但消费者还没读到Leader 宕机了新选举的 Leader 没有这条数据消息就丢了。所以生产环境强制要求 min.insync.replicas2配合 acksall双保险才靠谱。这一套组合拳几乎每年面试都会被翻出来问必须烂熟于心。4. 消费组的分区分配与再均衡最容易翻车的环节消费组是我在实际运维中踩坑最多的部分。Kafka 的消费并行度、offset 管理、消息重复、消费停摆全部汇聚在这个模块。4.1 分区分配策略到底怎么选Kafka 提供了三种主要的分区分配策略RangeAssignor范围分配按 Topic 维度把每个 Topic 的分区按顺序分配给消费者。假设一个 Topic 有 12 个分区组内有 3 个消费者每个消费者分到 4 个分区看起来很均匀。但如果有多个 Topic 且分区数不一致会出现数据倾斜。比如 TopicA 有 5 个分区TopicB 有 2 个分区3 个消费者Range 策略下第一个消费者可能分到 TopicA 的 2 个分区加 TopicB 的 1 个分区最后一个消费者只分到 TopicA 的 1 个分区。RoundRobinAssignor轮询分配把所有 Topic 的全部分区看作一个整体按字典序排序后轮流分配给消费者。它能保证分区数相同的情况下分配最均匀避免多个 Topic 场景下的倾斜问题。StickyAssignor粘性分配在轮询的基础上尽量保持上一次的分区分配结果不变。如果只是某个消费者退出其他消费者的分区归属尽量不动只把退出的分区重新分配出去减少不必要的分区迁移。在 hood 里默认用 Range但如果是多 Topic 场景我强烈建议改成 Sticky 或者至少是 RoundRobin。Range 策略的倾斜问题在分区数多、Topic 多的时候会被放大消费者之间负载严重不均慢消费者反而成了瓶颈。4.2 再均衡的致命问题Stop-the-World再均衡Rebalance是整个消费者组最脆弱的时刻。触发条件包括消费者加入或退出、Topic 分区数变化、消费者心跳超时等。再均衡发生时整个消费组的所有消费者都会停止消费等待分区重新分配完成。这一停轻则几秒如果消费时间长或者分区数几千rebalance 可能持续几十秒甚至几分钟。更糟的是再均衡期间所有消费者都在等协调者完成分配而分配需要所有消费者上报自己的元数据一旦有一个消费者响应慢全组陪跑。我处理过最典型的生产事故是这样某个服务有 20 个消费者实例消费逻辑里有外部 RPC 调用偶尔耗时到 10 秒。Kafka 默认session.timeout.ms是 45 秒新版本默认值有变化很多还配置的是旧版默认但max.poll.interval.ms如果设置不当消费者处理一批消息的时间超过了这个阈值协调者就判定它死了触发 rebalance。一次 rebalance 后所有实例重新拉取消息又因为处理慢再次超时再触发 rebalance形成一个无限循环消费完全停摆。避免这个问题的核心思路有三个max.poll.records不要设太大减少单次 poll 拉取的消息量降低单批处理时长。max.poll.interval.ms要大于单批消息的最大处理时间并且留足余量宁可让消费者慢也不要让它被踢出组。消费逻辑里不要做阻塞操作比如同步的 RPC 调用、数据库大批量写入这些可以异步化不要让消费线程阻塞太久。4.3 offset 提交的方式与陷阱offset 是消费者在分区中的消费位置相当于书签。提交时机不对要么丢消息要么重复消费。自动提交enable.auto.committrue默认每 5 秒提交一次 offset。如果消费者在处理完一批消息后、还没到 5 秒提交间隔就宕机了重启后会从上次提交的位置继续消费中间这段消息就重复消费了。反向的问题也存在如果消费者拉取了消息还没处理完就被 killoffset 已经自动提交了这些消息就丢失了。手动提交enable.auto.commitfalse在业务代码里显式调用 commitSync 或 commitAsync。commitSync 是同步提交会阻塞直到提交完成保证提交成功但吞吐受影响commitAsync 是异步提交不阻塞但可能失败需要配合回调处理。我的实践建议是如果是处理结果需要持久化的场景采用先处理业务再提交 offset的顺序。也就是把消息处理完、业务数据落库之后再提交 offset。这样即使提交失败最多就是重复消费不会丢数据。而“先提交 offset 再处理业务”虽然在性能上更优但一旦处理失败消息就再也找不回来了。这两者的取舍必须根据业务对丢失和重复的容忍度来决定。5. 从面试题看出题人的心思消息丢失、重复消费与顺序不一致这一节专门分析高频面试题背后出题人想考察的本质。所谓消息丢失重复消费顺序错乱表面上是三类问题实际上考察的都是你能否把生产者、Broker、消费者三段链路串起来思考。5.1 消息丢失的可能环节与应对消息丢失只有三种可能生产者发到 Broker 的途中丢了。比如网络故障、Broker 尚未写入就返回异常、生产者发送失败后没有重试。应对方式是设置acksall表示消息必须被 ISR 中所有副本确认才算成功。同时设置retries为一个合理值默认是很大的值但更合理的是配合retry.backoff.ms设置避免重试风暴并且开启enable.idempotence幂等生产者这样即使重试也不会产生重复数据至少是在分区内不会产生重复。Broker 存储阶段丢了。比如消息写入 Leader 成功但 Follower 还没来得及同步Leader 宕机了新 Leader 没有这条消息。应对方式是设置min.insync.replicas2并配合acksall让消息必须写到至少两个副本才算成功。这能保证在单副本故障时数据仍然存在。Broker 持久化期间丢了。比如操作系统宕机页缓存里的数据还没来得及刷盘。应对方式是调整log.flush.interval.messages和log.flush.interval.ms不过这会影响性能通常不建议为了刷盘牺牲性能因为副本机制已经保证了另一台机器上有数据。消费者处理阶段丢了。比如消费者先提交了 offset再处理消息处理过程中崩溃消息就丢了。应对方式就是上面说的先处理后提交。5.2 重复消费的根源是至少一次语义Kafka 默认提供的是至少一次At-least-once送达语义也就是说在故障场景下消息可能被重复投递。这是由它的架构决定的消费者 offset 提交失败导致重启后从更早的位置重新消费或者生产者重试多次发送导致 Broker 写入重复消息幂等生产者能避免这一部分。实现精确一次Exactly-once有三种路径幂等生产者单分区内精确一次通过 PID 和序列号机制Broker 端去重。但只保证单分区内、单会话内不重复跨分区跨会话不保证。事务 API跨分区跨会话Kafka 的写事务能保证多条消息发送到多个分区的原子性配合隔离级别read_committed消费者只能读到已提交的事务消息。消费端幂等在业务层面做去重比如用数据库唯一键、Redis 记录处理过的消息 ID这是最通用也是最简单的方案。真实业务里我很少看到真的把事务 API 铺开到所有场景因为性能损失明显配置也复杂。大多数业务对重复的容忍度其实可以通过业务上的幂等设计来解决比如支付回调、状态机更新等场景天然是幂等的。只有真的无法在业务上幂等的场景才值得引入事务。5.3 严格顺序的场景与解法Kafka 保证顺序的手段很朴素同一分区内的消息是有序的。所以要保证消息顺序只需要让这些消息进入同一个分区。具体做法是生产者在发送消息时指定 keyKafka 根据 key 的哈希值决定分区。同一个 key 的消息永远进同一个分区消费者按分区顺序处理顺序就保住了。这里有几个隐含坑分区数一变哈希结果就变原本进同一个分区的 key 可能分散到不同分区顺序就乱了。所以如果业务强依赖顺序分区数一旦确定就不要随意扩容。消费者端如果用多线程消费同一个分区的消息顺序也会乱。Kafka 保证的是写入顺序 分区内顺序但如果消费端把消息丢进多个线程并发处理顺序是无法保证的。要让单分区内严格顺序消费端必须单线程处理或者用线程内队列保证先入先出。重试机制可能打破顺序。比如生产者开了幂等重试是有序的Kafka 会等待前一条成功后再发下一条但如果你配置了retries且消息 A 重试阻塞了消息 B 已经发给 Broker顺序就反了。幂等生产者解决的是重复问题不是乱序问题乱序问题的解法是max.in.flight.requests.per.connection1这会牺牲吞吐或者开启幂等并使用 Kafka 5.0 的乱序优化机制。6. 延迟消费的工程实践实现30 分钟后再处理热搜里有kafka 如何延迟30分钟消费这个需求在订单超时关闭、延迟通知、定时任务领域经常遇到。Kafka 原生不直接支持延迟消息但可以组合出来。6.1 最简单的方案利用时间戳字段加定时轮询生产者在发送消息时带上一个期望执行时间字段消费者收到消息后判断当前时间是否已经达到执行时间如果没到把消息重新放回 Kafka发送到一个延迟重试 Topic或者消费者线程再 sleep 一段时间后重新 poll。这种方案的优点是实现简单缺点是消费者会频繁 poll 到未到期的消息CPU 和网络带宽有损耗延迟精度也不高。适合延迟时间固定的小场景比如固定延迟 30 秒、60 秒这种。6.2 工程上更靠谱的方案延迟队列与时间轮在 Kafka 之外叠一层延迟队列比如 Redis ZSet 实现把消息放到 ZSet 里score 设为期望执行时间一个专门的调度任务每隔几秒扫描一次 ZSet 中 score 小于当前时间的消息取出来发送到真实的 Kafka Topic。时间轮Timing Wheel的方案更高级一些Kafka 内部本身就使用了时间轮来做延迟操作比如延迟重试、延迟心跳检测。你在业务侧也可以自己实现一个时间轮调度器把延迟消息按时间槽组织轮询到期的槽位批量取出消息发送。还有一类思路是利用 Kafka 自身的延迟主题把延迟 N 分钟的消息发送到一个内部 Topic启动一个消费者专门消费这个内部 Topic如果当前时间未达到执行时间就重新发送达到之后转发到真正的业务 Topic。这种方案不需要引入 Redis 等外部依赖但会占用额外分区和 Broker 带宽。我的实际工程经验是延迟场景千万别在 Kafka 消费端 sleep否则一个消费者线程 sleep 期间它持有的分区全部停摆。把延迟逻辑放到独立调度的组件里而不是放进消费者的核心链路。6.3 延迟精度与 Kafka 的取舍用 Kafka 做延迟消息有个天然的精度问题。因为消费者 poll 的批次大小和间隔时间决定了消息从到期到真正被处理之间还有一段延迟差。比如max.poll.records500一批消息里有到期时间各不相同最晚到期的和最早到期的可能差了 5 分钟但消费者却一次性全部拉出来。解决思路是对消息做二次筛选消费者拉取后先把未到期的消息单独放回一个延迟缓冲池内存队列只处理到期的部分。这个方案比 sleep 高明不少因为它不会阻塞分区消费进度只是把消息暂时存档在内存。如果再配合 Kafka 的 pause/resume 机制暂停某分区拉取等延迟到了再恢复可以在不丢消息的前提下实现可靠的延迟消费。7. 部署与监控的实战经验分区数规划、参数调优与排查路径最后这部分聊一点生产环境里的实际取舍。Kafka 不像 Redis 那样拿来即用它的很多参数需要根据业务做规划规划失误的代价在用户量增长后会非常痛苦。7.1 分区数到底应该怎么定这个问题的万能回答是看吞吐量和需要的并行度。但更实操的判断方法要结合三个因素评估。第一是消费端并行度。一个分区在同一时刻只能被一个消费者实例消费同一个消费组内所以如果希望该 Topic 能被 N 个消费者实例并行消费至少要有 N 个分区。第二是生产端吞吐目标。单分区写入性能受限于单 Broker 的磁盘 I/O 和网络带宽通常单个分区的写入能力可以到几十 MB/s如果生产吞吐需要 200 MB/s至少需要 4 到 6 个分区。第三是端到端延迟。大数据量的 Topic 分区数越多单个分区上的数据量越小消费者处理完一个分区的耗时越短。分区数过少可能导致单分区数据堆积严重延迟增大。但分区数不是越多越好。每个分区都有对应的 Leader 副本和 Follower 副本占用 Broker 的文件句柄、内存和网络连接。分区数过多Broker 之间的副本同步开销成倍增长反而可能降低整体吞吐。常规的经验值Topic 分区数建议不超过 Broker 数量的 3 到 4 倍单 Broker 分区数所有 Topic 累加不建议超过 2000。这个值不是绝对标准但作为初始规划已经足够。7.2 flink 消费 kafka 写入 es 场景的参数组合热词里有flink消费kafka写入es这类实时链路我调过不少。关键点在于 Flink 端 Kafka Consumer 的参数要配合 checkpoint 机制设置。核心原则是Kafka offset 的提交交给 Flink checkpoint 管理而不是 Kafka 消费者的自动提交。具体配置是enable.auto.commitfalse让 Flink 在 checkpiont 成功时统一将 offset 提交到 Kafka这样 Kafka 端的 offset 和 Flink 的状态就是一致的。写入 ES 时为了让吞吐足够高通常设置sink.bulk-flush.max-actions比如 1000 条批量写入和sink.bulk-flush.max-size比如 5MB并且开启sink.bulk-flush.interval做定时 flush防止数据在内存里堆积太久。ES 侧如果写入压力大要关注 bulk 拒绝rejection这通常表现为 Kafka 消费延迟上涨而 CPU 未打满排查时要先看 ES 的线程池队列和性能指标。实时链路的问题链路特别长从 Kafka 到 Flink 到 ES每一环都可能成为瓶颈只看单环指标是不够的。7.3 常见故障的快速排查链路错误一Error while fetching metadata with correlation id这个错误在 Docker 环境里特别常见热词里也出现了。根本原因通常是客户端连不上 Broker或者获取元数据失败。排查路径看客户端配置的 bootstrap.servers 是否能从客户端所在网络访问到 Broker 端口。如果用了 Docker检查容器端口映射和 hostname 配置Kafka 的advertised.listeners必须配置为客户端实际能访问到的地址。用kafka-broker-api-versions.sh --bootstrap-server broker手工测试连通性。错误二消息延迟持续走高消息延迟高一般不是 Kafka 本身慢而是下游消费慢。优先排查消费者的 poll 耗时看单批消息处理时间是否超过max.poll.interval.ms看分区数是否只有 1 个而消费者有多个导致大部分消费者空闲看消费线程是否在等待外部资源数据库连接池满、RPC 超时。错误三磁盘空间持续增长Kafka 的消息保留策略默认按时间retention.ms和大小retention.bytes双条件生效。如果设置了全局保留 7 天但某个 Topic 数据量特别大需要单独为它配置retention.bytes或更短的retention.ms。排查时可以用kafka-log-dirs.sh查看各 Broker 的磁盘占用分布快速定位是谁在吃掉磁盘。监控层面Kafka 自身提供的 JMX 指标里我最常看这几个kafka.server:typeBrokerTopicMetrics,nameBytesInPerSec/BytesOutPerSec集群流量吞吐。kafka.server:typeReplicaManager,nameUnderReplicatedPartitions副本同步滞后分区数大于 0 说明有副本同步失败需要立刻处理。kafka.consumer:typeconsumer-fetch-manager-metrics,namerecords-lag-max消费者最大堆积量这个指标配合消息生产速率可以定位是生产快还是消费慢。我见过太多团队在 Kafka 出问题时一脸懵其实症结无非就这些分区数不匹配、消费者处理能力不足、副本同步异常、磁盘空间不够。只要建立了生产 - 存储 - 消费三段链路的监控意识大部分故障在 5 分钟内能定位到大方向再往下钻就只是时间问题。8. 从高频考点看学习路径哪些话术能让你在面试中加分聊完实战最后说说面试。Kafka 的面试题看起来千变万化但出题人的套路非常固定紧紧围绕高性能高可用一致性三个维度出招。一个加分的学习路径我认为是这样的先理解架构Broker、Topic、Partition、Replica 的协作关系。这部分是地基讲不清楚后面全崩。再掌握存储机制日志分段、顺序写、页缓存、零拷贝。回答Kafka 为什么快的时候把这四个词串成一条完整的逻辑链远胜于背诵零拷贝三个字。接着是副本与一致性ISR、HW、LEO 的更新过程acks 和 min.insync.replicas 的组合拳以及数据丢失发生在哪个环节的排查思路。面试官只要听到你能画出数据链路并指出每个环节的风险点基本就会认为你真正理解这道题。然后是消费者机制消费组、分区分配、rebalance 的触发条件与影响、offset 提交的语义。这部分特别容易暴露水平因为很多人只会用不理解重平衡的危害。最后是事务与精确一次幂等生产者、事务 API、消费幂等这是区分会用和精通的分水岭。我还想提醒一句现在很多面试都会顺带问 Pulsar 和 Kafka 的选型对比。如果你了解过 Pulsar 的分层架构计算与存储分离、Segment 存储到 BookKeeper 等会更容易理解 Kafka 在存储模型上的取舍。Kafka 的日志持久化是分区连续追加Broker 的存储与计算耦合Pulsar 把存储抽离成独立层支持更灵活的水平扩展但控制面和元数据管理的复杂度也上去了。这不是谁优谁劣的问题是不同取舍下适合不同业务的问题。以上就是我对 Kafka 核心原理和高频考点的整体拆解里面有我的实测经验也有这些年排查过的真实事故的复盘。Kafka 是个越用越有意思的组件它的设计思路放到任何分布式系统里都不过时吃透一套等于同时理解了消息队列的半个江湖。
