生产者
生产者的工程细节决定吞吐和可靠性。面试主线：发送流程、分区怎么选、acks 语义、幂等。
发送流程
生产者: 攒批发送是吞吐关键
- 批量（batch）：多条消息攒一个批次发，减少网络往返（吞吐核心）
linger.ms：攒多久（延迟换吞吐）；batch.size：批次大小- 异步发送 + 回调处理结果（同步 send 是反模式，慢）
分区策略
| 策略 | 机制 | 适用 |
|---|---|---|
| 指定分区 | 直接指定 | 强分区需求 |
| key 哈希 | 同 key 同分区 | 顺序保证（订单 id 哈希） |
| 粘性分区 | 攒批后选分区 | 默认，均衡 + 高效 |
key 是顺序的关键：需要顺序的消息用同一 key（同分区同序）。
acks 语义
| acks | 行为 | 可靠性 | 性能 |
|---|---|---|---|
| 0 | 发完不管 | 可能丢 | 最快 |
| 1 | leader 落盘确认 | leader 挂丢数据 | 快 |
| all | ISR 全部确认 | 不丢（配 min.insync） | 慢 |
生产推荐: acks=all + min.insync.replicas=2幂等与事务
- 幂等生产者（enable.idempotence=true）：相同批次重发不重复（序列号机制），默认开启
- 幂等只能防单分区内重复；跨分区原子性要事务（见顺序事务篇）
- 重试：网络错误自动重试（retries），幂等保证重试不产生重复
常见问题
| 问题 | 原因/解法 |
|---|---|
| 发送慢 | linger/batch 太小、acks=all 同步等待、网络 |
| 消息乱序 | 重试超时后批次乱序（幂等 + max.in.flight=1 可缓解） |
| 丢消息 | acks=0/1 + leader 挂、未开幂等重试 |
| 背压 | 缓冲满：调大 buffer.memory 或降生产速率 |
面试追问
- 生产者怎么做到高吞吐？ 攒批发送（linger + batch.size）+ 异步 + 分区并行
- acks=all 保证什么？ ISR 全部落盘才确认。配 min.insync.replicas=2 防单副本假确认
- 顺序怎么保证？ 同 key 同分区 + 分区内有序。幂等防重试重复
- 幂等生产者？ 序列号去重，防单分区重复。跨分区要事务
- linger.ms 调大？ 吞吐 ↑ 延迟 ↑。实时性敏感调小，吞吐优先调大