java kafka批量发送通过batch.size、linger.ms、compression.type及异步模式协同优化吞吐：batch.size设32–128kb摊薄协议开销；linger.ms设5–50ms攒批；lz4压缩减半载荷；异步发送+增大buffer.memory避免阻塞。
Java Kafka 在大数据传输场景中，批量发送是提升网络吞吐最直接、最有效的手段之一。它不依赖硬件升级或集群扩容，而是通过减少网络往返次数、摊薄单条消息的协议开销，把“零散发”变成“集中运”，从而显著放大单位时间内的数据传输量。
batch.size 控制批次容量，直接影响吞吐上限
该参数定义单个 ProducerBatch 的最大字节数（默认 16KB）。值设得越大，单次网络请求携带的消息越多，每字节的 TCP 包头、ACK、序列号等固定开销就被摊得越薄。
- 建议从 32KB（32768）起步，在内存充足（如 buffer.memory ≥ 128MB）的前提下逐步调高至 64KB 或 128KB；
- 注意避免过大导致单批发送耗时过长，尤其在网络带宽受限或消息体本身较大时；
- 可通过监控
record-queue-time-avg和request-latency-avg判断是否出现积压或延迟升高。
linger.ms 引入可控等待，让批次“攒得更满”
默认为 0，即有数据就发；设为 5–50ms 后，生产者会主动等待，争取把更多消息塞进同一个批次——这是平衡吞吐与延迟的关键杠杆。
- 对日志类、埋点类等容忍毫秒级延迟的场景，设 linger.ms=10–30ms 通常能带来 2–5 倍吞吐提升；
- 若业务要求端到端延迟 ≤ 10ms，可设为 1–5ms，仍优于纯逐条发送；
- 需配合 batch.size 使用：linger.ms 提供时间窗口，batch.size 提供空间上限，两者共同触发发送。
启用压缩，降低实际网络载荷
批量本身不减少字节数，但压缩能让一批消息“变得更轻”。Kafka 支持 lz4、snappy、zstd 等算法，其中 lz4 在压缩率与 CPU 开销间表现均衡。
- 配置
compression.type=lz4，服务端无需额外配置即可自动解压； - 实测在文本类消息（JSON/日志）场景下，lz4 可压缩 50%–70% 数据量，相当于同等带宽下吞吐翻倍；
- 注意：压缩在 Producer 端完成，CPU 占用略有上升，但远低于网络 I/O 和磁盘 I/O 的瓶颈效应。
配合异步发送与缓冲区调优，避免主线程阻塞
批量只有在异步模式下才能真正释放性能。同步发送或频繁 await send().get() 会让主线程卡在 ACK 上，彻底废掉批量价值。
- 确保使用
producer.send(record, callback)并提供回调处理结果，而非阻塞等待； - 增大
buffer.memory（如设为 128MB 或 256MB），防止高吞吐下 RecordAccumulator 快速填满导致TimeoutException； - 检查
max.in.flight.requests.per.connection（默认 5）：若不依赖严格顺序，可保持默认；若需保序且分区数多，可适当降低至 1。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
