Kafka 支持哪些压缩算法？生产环境怎么选？

Kafka 支持哪些压缩算法

Kafka 支持 Gzip、Snappy、LZ4、Zstd 四种压缩算法，以及不压缩（none）。压缩在生产者端以 batch 为单位执行，Broker 原样存储和转发，Consumer 端解压。理解各算法的取舍是选型的关键。

四种算法核心差异

Gzip：压缩率最高（文本数据可达 70-80%），但 CPU 开销大、速度慢。适合带宽极度受限、对延迟不敏感的场景。

Snappy：Google 出品，速度与压缩率较均衡，是 Kafka 早期版本的默认推荐。适合追求稳定、不想过度调优的常规业务。

LZ4：压缩和解压速度最快，CPU 消耗极低，但压缩率一般。适合高吞吐、低延迟的实时流处理场景。

Zstd：Facebook 开源，压缩率接近 Gzip，速度接近 Snappy，Kafka 2.1.0 起支持。是当前综合表现最优的选择。

快速对比：

算法	压缩率	压缩速度	CPU 消耗	Kafka 最低版本
Gzip	最高	慢	高	0.8.0
Snappy	中等	快	低	0.8.0
LZ4	较低	最快	极低	0.8.2
Zstd	高	较快	中等	2.1.0

生产环境怎么选

首选 Zstd：如果你的 Kafka 版本 >= 2.1.0，Zstd 几乎是最优解——压缩率比 Snappy 高 20-30%，速度远快于 Gzip，CPU 开销可控。

高吞吐场景选 LZ4：实时计算、日志采集等对延迟敏感的场景，LZ4 的极低 CPU 开销和最快解压速度更有优势。

老旧集群选 Snappy：无法升级 Kafka 版本时，Snappy 仍然是可靠的兜底方案。

Gzip 适合归档：只有"带宽贵过 CPU、数据量极大、延迟无所谓"的场景才考虑 Gzip，比如离线数据同步到冷存储。

配置要点

properties
# Producer 端配置
compression.type=zstd
batch.size=32768
linger.ms=10

batch.size 和 linger.ms 直接影响压缩效果——batch 越大，同一批消息的重复模式越多，压缩率越高。但 batch 过大也会增加延迟，需要权衡。

注意 compression.type=producer 是 Broker 端的默认值，表示"由 Producer 决定压缩方式"，Broker 不会主动解压或重新压缩。

常见追问

压缩对消息顺序有影响吗？ 没有。压缩以 batch 为单位，batch 内消息顺序不变，batch 之间也保持顺序。

Broker 端会解压吗？ 一般不会。Broker 收到压缩 batch 后直接落盘和转发。只有当 Broker 端配置了不同的 compression.type 时，才会解压再重压缩——这会浪费 CPU，应避免。

Consumer 端需要配置压缩算法吗？ 不需要。Kafka 在消息头中记录了压缩算法，Consumer 自动识别并解压。

选压缩算法本质上是在 CPU、带宽、存储三个资源之间做权衡。先明确瓶颈在哪，再对号入座，而不是盲目追求压缩率。