kafka生产者需协同配置batch.size和linger.ms：前者设批次字节数（如64kb），后者设强制发送等待时间（如10–50ms），并配套调优buffer.memory、compression.type等参数以平衡吞吐与延迟。
配置 Kafka 生产者批量发送大小（batch.size）和延迟（linger.ms），本质是控制“攒多少发一次”和“等多久发一次”。这两个参数必须配合使用，单独调大或调高都容易适得其反。
batch.size：按字节数触发发送的阈值
它定义单个批次最多容纳多少字节的消息数据。默认 16KB（16384 字节），实际效果取决于你每条消息的平均体积：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 若单条消息约 200B，16KB 批次 ≈ 80 条才触发发送；
- 若消息普遍在 50–100B（如埋点、指标类），可设为 64KB 或 128KB，让每批承载更多条数；
- 不建议盲目设到 1MB 以上——小流量场景下可能长期凑不满，导致消息滞留超预期；
- 上线前建议用真实消息体做压测：观察平均批次条数、端到端延迟分布、以及 buffer.memory 是否频繁打满。
linger.ms：兜底等待时间
即使 batch.size 没填满，也会在 linger.ms 到期后强制发送当前批次。默认是 0（有消息就发），这会带来大量小包：
- 常规业务推荐设为 10–20ms：兼顾延迟可控与批次利用率；
- 日志类突发写入（如秒级打点洪峰），可设为 5ms，避免积压；
- 订单状态流、ETL 同步等匀速中低频场景，可设为 30–50ms，进一步摊薄网络开销；
- 超过 100ms 需谨慎——端到端延迟敏感型服务（如实时风控）可能受影响。
配套关键参数不能漏
只调 batch.size 和 linger.ms 不够，还需同步优化支撑能力：
- buffer.memory：默认 32MB。若 batch.size 提高、并发量上升，需按比例上调（如 64MB 或 128MB），防止缓冲区满导致 send() 阻塞；
- compression.type：设为 lz4，压缩发生在 Producer 内存中，降低网络和磁盘负载，实测吞吐提升明显；
- max.in.flight.requests.per.connection：设为 5（开启幂等性后自动生效），允许多个批次并行发往同一连接，提升链路利用率；
- acks：设为 1 是吞吐与可靠性较优的平衡点，比 acks=all 少等 follower 响应。
