概述

Kafka目前支持GZIP、Snappy、LZ4、zstd、不压缩这几种压缩算法。在开启压缩时，Kafka会选择一个batch的消息一起压缩，这样的一批消息就是一个压缩分段，我们也可以通过参数来控制每批消息的大小。

在Kafka中，生产者生成一个压缩分段发给broker，在broker中是不会解压这个压缩分段的（因为在Kafka中一个batch的消息在broker中是不会拆分的，自然也不会进行解压），最后压缩分段由消费者进行解压。

Kafka通过这种设计，降低了broker中CPU资源的消耗，同时还能获得压缩后「占用传输带宽小，占用存储空间小」等好处，是非常值得我们借鉴和学习的。

一个坑点

我们平常在讨论Kafka压缩的时候一般只考虑生产者这一侧的压缩。实际上，在broker中如果触发了某些条件也是会进行解压和压缩操作的！反映到系统层面就会看到broker端CPU使用率飙升。

有两种触发条件：

1. broker端指定了和生产者端不同的压缩算法。
2. broker端发生了消息格式（V2 → V1，兼容老版本）转换，同时这种操作也会使Kafka丧失零拷贝的优势，进一步损失性能。这启发我们在生产环境中要尽量保证消息格式的统一。

在什么时候适合启用Kafka压缩功能

• 客户端（生产者、消费者）CPU资源充足。压缩毕竟是一种「时间换空间」的策略，如果能用系统长板来弥补短板的话那自然再好不过了。
• 带宽资源有限。目前带宽也是一种稀缺资源，尤其是对高吞吐的MQ而言，如果系统带宽成为瓶颈的话可以考虑开始消息压缩功能。→ 如果客户端机器 CPU 资源有很多富余，强烈建议开启 zstd 压缩，这样能极大地节省网络资源消耗。

几种压缩算法的性能对比

这张表是 Facebook Zstandard 官网提供的一份压缩算法 benchmark 比较结果：

可以看出：

• 吞吐量方面：LZ4 > Snappy > zstd 和 GZIP
• 压缩比（压缩前大小/压缩后大小）方面：zstd > LZ4 > GZIP > Snappy
• 具体到物理资源，Snappy占用的网络带宽最多，zstd 最少。在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。

参考自胡夕老师《Kafka核心技术与实战》极客时间专栏，老师的课很棒，强烈推荐！