Kafka 消息的发送过程简单介绍一下？

面试记录 2026-10-12

题目：Kafka 消息的发送过程简单介绍一下？

难度：medium

标签：db/mq/kafka, mq/kafka, difficulty/medium

评分：⭐⭐⭐☆☆（3/5）

我的回答

Kafka 消息的过发送的过程是这样的，由生产者发送消息，构建消息，将消息发送到 Broker 对应的 Topic 和 Partition 中。

订阅者再根据对应的 Object Partition 去读取对应的消息。

主流程了，然后具体过程是，生产者如果是要看你的需求，如果是要保证消息的一定可达，你需要做一些额外的操作。

关闭自动提交，然后只有在收到了对应的返回的时候才进行终止，否则进行重试。比如发送消息的时候，只有 Broker 返回发送成功了才结束，否则的话就进行重试。

消费者消费的时候也是一样的。消费消息关闭自动提交，然后只有收到了，处理完了之后才手动的提交，告知 Broker 这个消息收到了。对应的，另外需要保证防止消息重复，这时候需要设置一些幂等性的操作，比如通过消息的 ID 来确保这个消息是唯一的，还未消费过的，如果已经消费了，这个消息就进行丢弃。

点评

优点：

• 主链路清晰：Producer → Broker (Topic/Partition) → Consumer
• 意识到"可靠性"要靠手动提交 + 重试 + 幂等来保障，触达了核心思路
• 提到"幂等"这个概念，说明有分布式系统意识

不足：

• 完全没提生产者内部机制——Sender 线程 + RecordAccumulator + Partitioner，这是 Kafka 生产者的三大支柱
• 漏了 acks 参数——acks=0/1/all 是消息可靠性的开关，acks=all + min.insync.replicas=N 才能真正保证消息不丢
• 漏了批量参数——batch.size、linger.ms 是 Kafka 高吞吐的关键
• Producer 和 Consumer 的"关闭自动提交"混淆了——自动提交是 Consumer 侧概念（enable.auto.commit），Producer 侧不存在
• 幂等的说法过于简化：Kafka 的幂等靠 ProducerId + SequenceNumber，不是"消息 ID"

补充：

• Kafka 0.11+ 引入了 Producer 端幂等（enable.idempotence=true）+ 事务（transactional.id），可以做到 At-Least-Once 甚至 Exactly-Once
• Broker 侧的关键动作：ISR 副本同步 + min.insync.replicas 决定消息落几份副本才算 ack 成功
• Leader Replication 是异步的：Leader 落盘后立即 ack，Follower 复制通过后台线程

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对 Kafka Producer 内部机制的理解，尤其是"异步批量 + 分区路由 + ack 语义"这条主链路，判断候选人是否真正在业务里用过 Kafka。

知识点拆解：

1. Producer 四大组件：

• Sender：后台 IO 线程，负责实际发送请求
• RecordAccumulator：内存中的批次缓冲区（Deque），按 topic-partition 分桶
• Partitioner：决定消息路由到哪个 Partition，默认 hash(key) % numPartitions
• Metadata：本地缓存的集群元数据（Topic → Partition → Leader Broker）

1. 一条消息的完整路径：

• send() → 序列化 → partitioner 选分区 → 放入 RecordAccumulator 对应桶
• Sender 线程从 Accumulator 拉批次 → 发送请求给 Leader Broker
• Leader 落盘 → 通过 LeaderReplication 线程异步复制给 Follower
• Leader 按 acks 语义返回：acks=0 直接返回、acks=1 本节点落盘返回、acks=all 等 ISR 全部落盘

1. 关键参数：

• acks：0/1/all，可靠性 vs 性能权衡
• batch.size（默认 16KB）+ linger.ms（默认 0）：批量发送的触发条件
• buffer.memory（默认 32MB）：Accumulator 总容量，满了会阻塞 send()
• retries：发送失败重试次数
• max.inflight.requests.per.connection：影响是否乱序（>1 且未开启幂等会乱序）

1. 可靠性三档：

• At-most-Once：acks=0，可能丢
• At-least-Once：acks=all + enable.idempotence=true（默认 true，Kafka 3.x），重试不会重复
• Exactly-Once（语义）：Producer 端幂等 + Consumer 端事务（enable.idempotence=true + isolation.level=read_committed）

Kafka 生产者的高性能 = 异步批量 + 分区路由 + 压缩；可靠性 = acks + 幂等 + 事务。

第二部分：考察方向与延伸递进

考察方向：

• 深度：RecordAccumulator 的 Deque 结构、linger.ms 与 batch.size 的触发优先级、buffer.memory 满时抛 BufferExhaustedException
• 广度：与 RocketMQ 生产者对比（RocketMQ 是同步阻塞为主）、与 gRPC 的批量/流式对比
• 应用：如何在业务中权衡 acks 和延迟、如何处理 max.inflight.requests.per.connection > 1 导致的乱序、Producer 端背压如何排查

延伸递进面试题：

1. Producer 端 buffer.memory 满了会发生什么？

• 解答要点：send() 阻塞等待空闲批次，超过 max.block.ms 抛 TimeoutException；通常是生产者跟不上发送速率的背压信号

1. acks=all 一定能保证消息不丢吗？

• 解答要点：不一定。Leader 落盘后返回 ack 但 Follower 未及时同步、或 Leader 意外宕机且副本全部未落盘时可能丢；还需 min.insync.replicas + unclean.leader.election.enable=false

1. Kafka 0.11 之前的幂等生产者怎么实现重试不重复？

• 解答要点：0.11 之前没有幂等生产者，重试可能产生重复消息；要靠业务侧幂等（如唯一键去重）

1. sticky partitioner 是什么？

• 解答要点：Kafka 3.x 默认；在 key 为空时，同一 batch 内的消息粘到同一 partition，减少 rebalance 前的开销

第三部分：面试者参考回答（300-400 字口语化）

面试官您好，Kafka 生产者从 send() 到消息落盘，核心是"异步批量 + 分区路由 + ack 语义"这三个词。

第一，Partitioner 决定分区。消息先经过 Partitioner，默认是 hash(key) % numPartitions，同一 key 一定落同一分区；kafka 3.x 引入了 sticky partitioner，key 为空时会让同一批消息粘到同一分区，减少分区切换的开销。

第二，RecordAccumulator 负责攒批。消息不会立刻发出去，而是先进入 Accumulator 里按 topic-partition 分桶的 Deque。Sender 后台线程按两个条件触发发送：批次大小达到 batch.size（默认 16KB）或者等待时间超过 linger.ms（默认 0，即不攒）。这两个参数是 Kafka 生产者吞吐的关键调优点，攒批大了吞吐高但延迟也会涨。

第三，Broker 端 acks 语义决定可靠性。acks=0 直接返回可能丢；acks=1 Leader 落盘返回；acks=all 等所有 ISR 副本落盘。要真正保证不丢，需要 acks=all + min.insync.replicas >= 2 + unclean.leader.election.enable=false，再叠加 enable.idempotence=true（0.11+）避免重试产生重复。消费者侧配合 isolation.level=read_committed 就是端到端 Exactly-Once。

当然，攒批和 acks=all 都是有代价的：吞吐和可靠性换延迟；实际业务要按场景权衡，不是越高越好。