Producer 的吞吐瓶颈往往不在 broker，而在客户端自己——批量太小、压缩没开、acks 选错，都会让写入效率断崖。本文深入 Producer 的发送管线：批量怎么组、压缩怎么选、延迟与吞吐怎么权衡，以及错误与幂等怎么兜底。
1. Producer 的发送管线
1.1 从 send 到 broker 的旅程
Producer 的 send() 是异步的：消息先进本地缓冲，由后台发送线程批量发出：
# 发送管线
# send() → 分区器选分区 → 放入对应分区的 RecordBatch 缓冲
# → 达到 batch.size 或 linger.ms 到期 → 后台线程发送
# → broker 确认（acks）→ 回调触发（成功/失败）
# 缓冲上限: buffer.memory（默认 32MB），满了 send() 阻塞（max.block.ms）
关键认知：Producer 是「攒批发送」模型，单条 send 不会立刻触发网络请求。吞吐由「批大小 × 并发发送线程数」决定，延迟由「linger.ms 等待时间」决定。
1.2 三个决定批量的参数
- batch.size（默认 16KB）：单个分区的批次目标大小。不是硬上限——达到即发，未达到等 linger.ms。
- linger.ms（默认 0）：批次在缓冲里的最大等待时间。0 表示「能发就发」，批量靠并发天然形成。
- buffer.memory（默认 32MB）：总缓冲上限，满则 send 阻塞（保护内存）。
# 批量与吞吐的关系
# 每个批次有固定开销（请求头、连接往返）
# 批越大: 每字节分摊的固定开销越小 → 吞吐越高
# 但: 批越大，单请求延迟越高、尾部延迟抖动越大
# 权衡: 高吞吐批 + 低延迟场景调小 linger.ms 与 batch.size
2. 压缩：几乎免费的吞吐提升
2.1 压缩算法的取舍
Kafka 支持四种压缩：gzip、snappy、lz4、zstd。压缩发生在客户端（消息进 broker 前已压缩），broker 存储压缩后的字节。
# 四种压缩对比（典型值，随数据特征变化）
# lz4/snappy: CPU 开销低、压缩率中档 —— 吞吐优先场景
# zstd: 压缩率最高、CPU 略高 —— 省带宽与存储场景
# gzip: 压缩率中档、CPU 较高 —— 老场景兼容
# 注意: 压缩解压在消费端，高压缩率会拉高消费 CPU
工程经验：默认 lz4 或 zstd。lz4 延迟最低，zstd 压缩率最好。压缩比消息体积通常能降 50%~80%，对带宽与 broker 磁盘收益巨大，几乎必开。
2.2 压缩的边界
- 小消息：压缩头开销相对大，收益下降，但通常仍值得。
- 已压缩数据：对已压缩的 JSON/图片再压缩收益低，甚至略增。识别「不可压缩数据」可关掉对应主题压缩。
- CPU 预算：压缩耗 CPU，CPU 紧张且带宽充裕时权衡开与不开。
3. acks 与吞吐延迟权衡
3.1 三种 acks 语义
- acks=0：不等确认，可能丢（leader 崩溃或网络故障）。吞吐最高，能接受丢。
- acks=1：Leader 写入即确认。leader 崩溃时可能丢已确认数据。吞吐与可靠性的默认折中。
- acks=all：ISR 全部写入才确认。不丢（配合 min.insync.replicas），但延迟最高。
# acks 选择的工程判断
# 日志/监控/可丢场景: acks=0 或 1（吞吐优先）
# 订单/风控/账务: acks=all + min.insync.replicas≥2（一致性优先）
# 折中: acks=1 + 重试 + 幂等（大多数业务）
3.2 acks 与批量调优的联动
acks=all 时，Leader 要等副本确认，批次的吞吐受限于 ISR 的同步速度。若 ISR 健康，acks=all 与 acks=1 的吞吐差距不大；若副本落后，acks=all 会明显拉低写入吞吐——此时优先解决副本落后，而非降 acks。
4. 分区器与 key 路由
4.1 分区选择逻辑
Producer 默认按 key 哈希选分区：同 key 同分区（保证同一实体的消息有序）。无 key 时轮询（RoundRobin/Sticky）。
# 分区路由
# key 存在: hash(key) % numPartitions → 固定分区
# key 不存在: 轮询/粘性分区（sticky：尽量连续发同一分区攒批）
# 注意: 分区数变更会使 hash 路由结果变化（有序性跨分区失效）
工程要点：业务有序性依赖 key。同实体（用户/订单）的消息必须同 key 才能保证分区内有序；跨分区就没有全局顺序。
4.2 分区器与批次分配
**粘性分区器（Sticky Partitioner）**是 2.4+ 默认：一批消息尽量发同一分区，攒更大的批、减少请求数。相比纯轮询，粘性对吞吐提升明显。若业务需要「多分区并行写」，可调大分区数配合。
5. 幂等生产者与事务
5.1 幂等生产者（enable.idempotence）
幂等生产者给每条消息加 producerId + sequence，broker 端去重。重试产生的重复消息会被 broker 丢弃，消除「网络重试导致重复」这一最隐蔽的重复源。
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
# 前提: acks=all（幂等要求 acks=all）
# 效果: 重试不产生重复，消息只写一次
# 代价: 单 producer 的吞吐略有下降（序列号维护）
幂等只对单 producer 单会话有效，不覆盖「应用重启后新 producer 的重发」——端到端不重复需要消费端幂等或事务。
5.2 事务：跨分区原子的写入
enable.idempotence + transactional.id 启用事务：一批消息要么全部可见、要么全部不可见（跨分区原子）。配合 acks=all，事务提供「读事务消息的消费者看不到半成品」的语义。注意事务有额外协调开销，只有真正需要「全有或全无」的业务才用（如 read-process-write 模式）。
6. 错误处理与重试
6.1 可重试与不可重试错误
# 可重试错误（Retriable）: 会自动重试，如连接断、leader 选举中、队列满
# retries（默认 INT_MAX）+ retry.backoff.ms 控制
# 不可重试错误（Fatal）: 不会重试，如消息太大、认证失败、序列化错误
# 幂等开启时重试是安全的（去重），未开启则重试可能重复
6.2 回调与失败兜底
- 回调（Callback）：
send()的回调里处理失败——记录、重试、进 DLQ，不要静默吞掉。 - delivery.timeout.ms：整体投递超时（含排队 + 重试），超过即失败。设得太短会来不及重试。
- max.block.ms：缓冲满时 send 阻塞上限，超过抛异常——高峰期要预留缓冲余量。
# 一个稳健的失败处理范式
# send(msg, (metadata, ex) -> {
# if (ex != null) { 记录失败 → 按错误类型重试/进重试队列/告警 }
# });
7. 吞吐调优清单
按「先批量、再压缩、再并发」的顺序调：
- 开压缩：
compression.type=lz4（或 zstd），立竿见影。 - 调批量：
batch.size=32KB~128KB、linger.ms=5~20ms——高吞吐场景用大批；低延迟场景保持小批。 - 调并发：Producer 支持多实例并行发送，按业务并发度拆分；
max.in.flight.requests.per.connection=5（幂等时默认 5）。 - 监控指标：
record-queue-time-avg（排队耗时）、batch-size-avg、records-per-request-avg、request-latency-avg——看批量是否形成、延迟在哪。 - 避免单 topic 分区太少：分区数过少会限制并发写并行度。
# 高吞吐配置示例
# compression.type=zstd
# batch.size=65536
# linger.ms=10
# acks=1
# enable.idempotence=true
# 配合: 分区数 ≥ 32（给足并行度）
8. 常见坑清单
- linger.ms=0 期望高吞吐：没有等待窗口，批大小主要靠天然并发，小流量下吞吐上不去。
- 不开压缩怪带宽不够：压缩是带宽最便宜的解锁方式，先试它。
- 幂等与 acks=0 冲突：幂等要求 acks=all，配错会直接报错。
- 回调吞异常：失败静默等于消息丢进黑洞，务必记录与兜底。
9. 总结
Producer 调优的本质是「在吞吐与延迟之间找业务可接受的切点」：批量（batch.size/linger.ms）决定吞吐，压缩（zstd/lz4）几乎免费提吞吐，acks 决定可靠性档位，key 决定有序性，幂等与事务消除重试重复。落地顺序：先开压缩、再调批量与 linger、按业务定 acks 与幂等、最后用监控指标回归验证。记住：Producer 是攒批发送的异步模型，吞吐的杠杆在客户端参数里，不在 broker 配置里。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。