Kafka通过生产者端消息批次压缩显著降低网络带宽占用，压缩由Producer配置compression.type触发，Broker与Consumer仅透传和解压；支持snappy、lz4、zstd、gzip，推荐lz4或zstd；压缩效果依赖数据类型与batch.size，本质是CPU与带宽的权衡。
Kafka 通过在生产者端对消息批次（Batch）进行压缩，把多条消息打包后统一压缩再发送，从而显著减小传输数据体积，直接降低网络带宽占用。
压缩发生在生产者端，不是 Broker
压缩由 Producer 主动触发，配置 compression.type 参数即可启用。Broker 和 Consumer 不参与压缩计算，只负责透传和解压。这意味着压缩收益从源头开始，避免了原始消息在网卡上“裸奔”。
- 支持的算法包括：snappy、lz4、zstd、gzip
- 推荐优先选 lz4 或 zstd：压缩率适中、CPU 开销低、解压速度快
- 不建议在 CKafka 环境使用 gzip：服务端额外 CPU 消耗高，且需预留大量带宽余量（如原带宽 40MB/s，开启 gzip 后建议升至约 160MB/s）
压缩效果取决于数据类型和批次大小
文本类数据（如日志、JSON）压缩率高；二进制或已压缩数据（如图片 base64、加密 payload）几乎无收益，甚至可能略微膨胀。
- 典型压缩率参考（文本日志场景）：gzip≈75%、zstd≈70%、snappy≈50%、lz4≈40%
- batch.size 越大，单位消息的压缩开销越摊薄，整体压缩效率越高
- linger.ms 配合使用，可等待更多消息攒批，提升压缩率，但会增加端到端延迟
压缩是 CPU 和带宽之间的权衡
它本质是用计算时间换网络资源——压缩快慢、解压快慢，直接影响 Producer 和 Consumer 的吞吐与延迟。
- CPU 闲、带宽紧 → 适合开启压缩，尤其选 zstd（高压缩比+可控速度）
- CPU 紧、带宽足 → 关闭压缩或选 lz4/snappy，避免加重瓶颈
- 若 Consumer 端频繁读取+解压，还要评估磁盘 IO 与解压开销是否划算
验证压缩是否生效很简单
不用看代码，直接查监控指标或日志：
- Producer 端观察 compression-rate-avg 指标，值 > 0 表示已压缩
- 对比开启前后网络出口流量（如 ifconfig 统计、云厂商带宽监控），下降明显即有效
- Broker 端查看 bytes-in-per-sec，压缩后该值应显著低于未压缩时的原始消息体积
