批量发送、压缩和吞吐延迟怎么权衡

先说结论

• Kafka 生产端的吞吐优化，核心通常在批量和压缩
• 批量越大，吞吐通常越高，但发送时延往往也会更大
• 压缩能明显减少网络和磁盘开销，但会增加 CPU 成本

一、为什么 Kafka 总在讲批量

因为 Kafka 不是按“单条消息最优”设计的，而是按“批量顺序写日志”设计的。

这意味着：

• 多条消息凑成 batch 发，往往更省
• broker 落盘、网络传输、复制同步也更高效

所以一旦你追求高吞吐，通常都会碰到两个参数思路：

• 攒多久再发
• 攒多大再发

二、批量能带来什么

批量发送通常能带来：

• 更少的网络请求次数
• 更高的 broker 写入效率
• 更好的压缩效果

但代价也很明确：

• 单条消息可能要等一下
• 高峰和低峰的表现会不一样
• 小流量场景下收益不一定明显

三、压缩为什么常常值得开

Kafka 场景里，压缩通常不是“锦上添花”，而是很常见的基础优化。

因为压缩后通常会降低：

• 网络传输成本
• broker 磁盘写入量
• 副本复制流量

常见取舍可以粗略理解成：

• lz4：更偏均衡，延迟和吞吐表现常常比较稳
• snappy：实现简单，老系统里很常见
• zstd：压缩率更高，但更吃 CPU

四、什么时候更看吞吐，什么时候更看延迟

更偏吞吐的场景

• 日志采集
• 埋点上报
• 流式数据同步
• 批量异步任务

这类场景通常更愿意接受：

• 稍高一点发送时延
• 更大的 batch
• 更积极的压缩

更偏延迟的场景

• 支付结果通知
• 订单状态流转
• 库存异步校正

这类场景就不能一味追求大批量，否则端到端时延会被明显拉高。

五、最容易踩的坑

1. 一味调大批量参数

吞吐可能上去了，但业务方会先感知到消息延迟变大。

2. 只看 producer 指标，不看 broker 和消费者

发送吞吐上去之后，broker 磁盘、网络、consumer lag 可能会跟着变差。

3. 所有 Topic 用一套策略

日志 Topic 和交易 Topic 的目标根本不一样，不适合完全同配。

总结

Kafka 里“批量、压缩、吞吐、延迟”本来就是一组权衡题，没有一组参数能同时把所有指标都拉满。日志流更偏吞吐，交易流更偏时延，先分清业务目标，再决定 batch 和压缩策略，效果会稳很多。