4. Kafka生产者原理与面试题
Kafka生产者并不是“调用send就把消息发出去”这么简单。一次send()调用背后，消息要经过拦截器、序列化器、分区器，被追加到RecordAccumulator的批次中，再由Sender线程按broker维度聚合发送，失败后还要按重试机制回退。面试中这一章几乎必问，因为它同时考察API使用、线程模型和可靠性设计。下面按消息在主线程与Sender线程中的流转顺序展开。
一、主线程侧：拦截器、序列化器、分区器
生产者主线程调用KafkaProducer.send()后，消息依次经过三个组件。
拦截器（ProducerInterceptor）是最先执行的，接口只有onSend和onAcknowledgement两个核心方法。onSend在序列化之前调用，可以修改消息内容或统计发送量；onAcknowledgement在消息被确认或失败时回调。典型用途是埋点监控和消息统一加工。注意拦截器运行在生产者主线程，逻辑过重会直接拖慢发送吞吐。
序列化器（Serializer）把对象转成字节数组。常用的是StringSerializer、ByteArraySerializer，自定义对象可实现Serializer<T>接口，在serialize()中写入字节。key和value各自独立配置，例如key.serializer与value.serializer。序列化失败会直接抛异常，不会进入累加器。
分区器（Partitioner）决定消息进入哪个分区。默认实现DefaultPartitioner的规则是：key不为null时，对key做murmur2哈希再对分区数取模；key为null时，使用粘性分区策略，在一批消息内固定选一个分区，写满或达到时间阈值后再切换，以减少小批次。若业务需要按自定义规则路由，可实现Partitioner接口并在partitioner.class中指定。
面试常问：分区数增加后，相同key的消息还会进同一分区吗？不会。因为取模的分区数变了，历史消息和新消息可能落到不同分区，顺序性被破坏。所以依赖key顺序的场景，应提前规划分区数，或改用业务层保证顺序。
二、RecordAccumulator：批次缓冲的核心
分区确定后，消息被追加到RecordAccumulator。它的内部结构是ConcurrentMap<TopicPartition, Deque<ProducerBatch>>，每个分区对应一个双端队列，队列里是待发送的批次。
关键参数是batch.size（默认16384字节）和linger.ms（默认0）。消息先尝试放入队列尾部未写满的批次；放不下就新建一个ProducerBatch。批次大小由batch.size控制，但单条消息超过该值时也会单独成批。linger.ms是发送前的等待时间，适当调大（如5～20ms）能让更多消息凑成一批，提升吞吐，代价是增加延迟。
累加器还有总内存上限buffer.memory（默认32MB）。当缓冲区被占满，send()会阻塞，超过max.block.ms（默认60秒）则抛TimeoutException。面试中常被追问“生产者发送变慢甚至卡住”，答案往往指向缓冲区耗尽或Sender发送不及时。
三、Sender线程：真正的网络发送
Sender是生产者唯一的后台发送线程，在run()中循环执行：从累加器取出已就绪的批次，按目标broker分组，向对应broker发起ProduceRequest。
“就绪”的判断条件是：批次已写满，或等待时间超过linger.ms，或累加器中等待的批次数量达到阈值。Sender会优先发送已就绪的批次，并把同一broker的多个批次合并到一次请求中，这就是批处理带来的网络效率。
发送完成后，broker返回响应，Sender根据响应结果决定是回调成功还是进入重试。整个过程中，主线程只负责写缓冲，网络IO全部由Sender承担，这是Kafka生产者高吞吐的关键设计。
四、重试机制与幂等性
发送失败时，是否重试由retries（默认Integer.MAX_VALUE）和retry.backoff.ms（默认100ms）控制。可重试异常包括网络抖动、Leader切换等；不可重试异常如序列化失败、消息过大则直接失败。
重试会带来两个问题：消息重复和消息乱序。默认情况下，若前一批重试，后一批可能先成功，导致同一分区内顺序错乱。要解决这两个问题，需开启幂等性：
enable.idempotence=true
acks=all
max.in.flight.requests.per.connection=5幂等性通过Producer ID和序列号，让broker对重复批次去重，同时保证单分区内有序。开启幂等后，retries必须大于0，acks必须为all，且max.in.flight.requests.per.connection不超过5。若要跨会话、跨分区保证精确一次，则需配合事务：transactional.id加initTransactions、beginTransaction、commitTransaction。
五、面试高频问题与判断依据
1. 消息发送流程是怎样的？按“拦截器→序列化器→分区器→RecordAccumulator→Sender→broker”回答，并说明主线程与Sender线程的分工。
2. 如何提高吞吐？增大batch.size、适当调大linger.ms、增加buffer.memory、使用压缩（compression.type=lz4或zstd）、提高max.in.flight.requests.per.connection。但要注意延迟与顺序性的权衡。
3. 如何保证不丢消息？设置acks=all、retries足够大、开启幂等性，并在业务侧处理回调异常。仅靠acks=1在Leader宕机时仍可能丢消息。
4. 如何保证顺序？同一key进同一分区，且开启幂等性避免重试乱序；若分区数变化，需重新评估key路由。
5. 发送超时怎么排查？先看buffer.memory是否耗尽、linger.ms是否过大、broker是否响应慢，再结合record-queue-time-avg、request-latency-avg等指标定位。
六、可直接对照的生产者参数检查表
| 参数 | 默认值 | 作用 | 调优方向 |
|---|---|---|---|
| batch.size | 16384 | 单批次字节上限 | 吞吐优先可调至65536 |
| linger.ms | 0 | 发送前等待时间 | 5～20ms提升批处理 |
| buffer.memory | 33554432 | 累加器总内存 | 高吞吐场景调大 |
| acks | 1 | 确认级别 | 可靠性优先用all |
| retries | MAX_VALUE | 重试次数 | 配合幂等使用 |
| enable.idempotence | false | 幂等去重 | 要求不重不乱时开启 |
| max.in.flight.requests.per.connection | 5 | 单连接未确认请求数 | 幂等下不超过5 |
把这条链路串起来记：拦截器改消息，序列化器转字节，分区器定去向，累加器攒批次，Sender发网络，重试与幂等保可靠。面试时能按顺序讲清每一步的输入、输出和关键参数，就已经超过大多数候选人。