Kafka生产者吞吐性能提升关键在于batch.size与linger.ms协同调优：前者控制批次字节数（建议64KB～1MB），后者决定等待时长（推荐10～50ms），二者需依消息体积分布联动设置，配合snappy压缩可进一步提升吞吐。
Kafka 生产者吞吐性能的跃升，核心就卡在 batch.size 和 linger.ms 这两个参数的协同上。它们不是各自调大就行，而是要像齿轮咬合一样配合业务消息特征来设。
batch.size 决定“一车拉多少”
这是单个批次的最大字节数，默认 16KB。设大了，一次网络请求能塞进更多消息，显著减少 TCP 往返次数。但注意：它不是按条数算的，是按字节。比如你平均消息大小是 5KB，batch.size=64KB，那一个 batch 最多装 12 条；如果消息忽大忽小（比如混着 100B 的心跳和 800KB 的日志），实际填充率可能很低，反而浪费等待时间。常见合理范围是 64KB～1MB。日志类场景常用 512KB，风控类小消息多的场景建议从 32KB 起步试。
linger.ms 控制“等不等、等多久”
它让生产者在 batch 没满时也愿意多等一会儿，攒够再发。默认是 0（有消息立刻发），这对延迟敏感场景友好，但吞吐低。设成 5ms 是低延迟底线；10～50ms 是多数业务的甜点区间；超过 100ms 就得警惕端到端延迟超标——尤其在要求 100ms 内闭环的实时风控或交易链路里，linger.ms=100 配合高并发写入，极易触发缓冲区积压甚至 OOM。
二者必须联动看，不能孤立调
- 如果
batch.size设得大，但linger.ms还是 0，那小消息永远凑不满 batch，白白浪费批处理优势； - 如果
linger.ms设得长，但batch.size太小，batch 很快就满了，linger 根本没机会起作用； - 最危险的是：
linger.ms=100+max.in.flight.requests.per.connection=5同时开，多个未确认 batch 在内存里堆叠，buffer.memory 不够直接触发阻塞或崩溃。
实操建议
- 先摸清自己消息的典型体积分布（用监控或抽样统计）；
- 初期可设
batch.size=65536（64KB）、linger.ms=10，跑压测看 TP99 延迟和吞吐拐点； - 若吞吐上不去但延迟尚可，尝试把
linger.ms逐步加到 20～30，观察 batch 平均填充率（通过 Kafka Metrics 中record-send-rate和batch-size-avg对比判断）； - 同步打开
compression.type=snappy，能再榨取 30%+ 网络吞吐红利，CPU 开销可控。
不复杂但容易忽略。
立即学习“Java免费学习笔记（深入）”；
