kafka生产者异步发送的性能提升依赖batch.size与linger.ms协同调优、lz4压缩、buffer.memory扩容、max.in.flight.requests.per.connection设为5并启用幂等性，以及acks=all和高retries重试策略共同保障吞吐与可靠性。
Java Kafka 生产者异步发送本身不是“开关式”配置，而是靠背后一批关键参数协同作用来平衡吞吐量与可靠性。真正起效的不是“是否异步”，而是如何让异步背后的批量、缓冲、重试和确认机制既不拖慢速度，也不丢消息。
batch.size 与 linger.ms 协同调优
这两个参数决定“什么时候把攒好的消息发出去”，是吞吐与延迟平衡的第一道关口。
- batch.size 默认 16KB（16384 字节）：适合单条消息约 200B 的场景；若消息普遍更小（如 50–100B），可提升至 32KB 或 64KB，让每批装更多条，减少网络请求次数
- linger.ms 默认为 0（有消息立刻发）：容易产生大量小批次；设为 5–20ms 是通用推荐值，给小流量留出凑满 batch 的时间；匀速写入场景（如订单状态流）可尝试 30–50ms，但需避免业务端感知明显延迟
- 切忌只调大 batch.size 而忽略 linger.ms——低流量下消息可能卡在缓冲区超时才发出；也别只设 linger.ms 而不调 batch.size——高并发时仍会频繁触发小批次
启用压缩降低传输开销
压缩发生在 Producer 端内存中，不增加 Broker 压力，却能显著减少网络带宽和磁盘 IO，间接提升吞吐并缓解网络瓶颈。
- 推荐使用 lz4：CPU 开销低、压缩率适中、解压快，实测比 snappy 更均衡；配置方式简单：
props.put("compression.type", "lz4") - gzip 压缩率更高，但 CPU 消耗大，仅在带宽极度受限且机器 CPU 富余时考虑
- 对极小消息（如
缓冲区与并发控制参数
缓冲容量和未确认请求数直接影响主线程是否阻塞、Sender 线程能否高效运转。
- buffer.memory 默认 32MB：若持续高吞吐或消息体较大（如含图片 base64），建议上调至 64MB 或 128MB，防止 RecordAccumulator 满导致 send() 阻塞或抛异常
- max.in.flight.requests.per.connection 默认 5：控制每个连接上最多几个未确认请求；设为 1 可保分区级顺序但严重限制吞吐；设为 5 并配合幂等性，是吞吐与顺序兼顾的常用组合
- 开启幂等性（
enable.idempotence=true）后，Kafka 自动将 max.in.flight.requests.per.connection 限制为 5，同时保障不重不丢
可靠性兜底：重试与 ack 配置
异步不等于不可靠，关键靠重试策略和确认级别兜底。
- acks=all：要求 ISR 中所有副本都写成功才返回确认，是强可靠性前提；配合幂等性使用效果最佳
-
retries 设为较大值（如
Integer.MAX_VALUE或 2147483647）：配合retry.backoff.ms（默认 100ms）实现自动退避重试，避免因瞬时网络抖动丢消息 - 务必使用带回调的异步发送（
producer.send(record, callback)）：回调中处理 Exception，但不要在回调里做耗时操作或手动重试——重试已由 Producer 内置机制完成
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
