Kafka 生产者压缩算法是什么？何时压缩和解压？什么压缩性能好？

---

压缩（compression）是为了节省空间，并且减少I/O传输量。希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输。

何时压缩？

Kafka 中，压缩可能发生在两个地方：生产者端和 Broker 端。

如果在生产者段定义压缩方式就这样写，开启GZIP压缩算法。官网中有说明

默认为none

在Broker和topic也可以配置

查看官方文档可知，在Broker.kafka配置文件中可以配置，在Topic启动参数中也可以配置


通过之前学过的可知 当topic有配置时候会覆盖Broker的配置，并且topic和Broker的默认配置都是producer

默认条件下Broker和topic都尊重 producer的压缩选择。
优先级可以当做（而不是真的当做） topic>Broker>producerr，而具体情况下不要出现以下这种情况：

Broker 端指定了和 Producer 端不同的压缩算法。

白白浪费了资源，而且 Broker 端CPU使用率飙升。

Broker 端发生了消息格式转换。

消息格式转换主要是为了兼容老版本的消费者程序。为了兼容老版本的格式，Broker 端会对新版本消息执行向老版本格式的转换。这个过程中会涉及消息的解压缩和重新压缩。一般情况下这种消息格式转换对性能是有很大影响的，除了这里的压缩之外，它还让 Kafka 丧失了引以为豪的 Zero Copy 特性。

何时解压缩？

Consumer端解压缩、Broker 端也会进行解压缩，在以上介绍中已经大致掌握了压缩解压情况。就不具体重复。

什么压缩性能好？

GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。但对于 Kafka 而言，它们的性能测试结果却出奇得一致，即在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；而在压缩比方面，zstd > LZ4 > GZIP > Snappy。具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比；在 CPU使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。