【kafka实践】07｜kafka消息压缩

关于压缩（compression），你一定不会感到陌生。经典的用时间去换空间思想，就是用 CPU 时间去换磁盘空间或网络 I/O 传输量，希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输。本节我们就来聊一聊 Kafka 消息压缩。

压缩

Kafka 是如何压缩消息的呢？首先从 Kafka 的消息格式说起了。目前 Kafka 共有两大类消息格式， V1 和 V2 版本。V2 版本是 Kafka 0.11.0.0 中正式引入的。不论是哪个版本，Kafka 的消息层次都分为两层：消息集合（message set）以及消息（message）。一个消息集合中包含若干条日志项（record item），而日志项才是真正封装消息的地方。Kafka 底层的消息日志由一系列消息集合日志项组成。Kafka 通常不会直接操作具体的一条条消息，它总是在消息集合这个层面上进行写入操作。

在 V1 版本中，每条消息都需要执行 CRC 校验，但有些情况下消息的 CRC 值是会发生变化的。比如在 Broker 端可能会对消息时间戳字段进行更新，那么重新计算之后的 CRC 值也会相应更新；再比如 Broker 端在执行消息格式转换时（主要是为了兼容老版本客户端程序），也会带来 CRC 值的变化。鉴于这些情况，再对每条消息都执行 CRC 校验就有点没必要了，不仅浪费空间还耽误 CPU 时间，因此在 V2 版本中，消息的 CRC 校验工作就被移到了消息集合这一层。

V2 版本还有一个和压缩息息相关的改进，就是保存压缩消息的方法发生了变化。之前 V1 版本中保存压缩消息的方法是把多条消息进行压缩然后保存到外层消息的消息体字段中；而 V2 版本的做法是对整个消息集合进行压缩。显然后者应该比前者有更好的压缩效果。

在 Kafka 中，压缩可能发生在两个地方：生产者端和 Broker 端。生产者程序中配置 compression.type 参数即表示启用指定类型的压缩算法。比如下面这段程序代码展示了如何构建一个开启 GZIP 的 Producer 对象：

 Properties props = new Properties();
 props.put("bootstrap.servers", "localhost:9092");
 props.put("acks", "all");
 props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
 props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
 // 开启GZIP压缩
 props.put("compression.type", "gzip");
 
 Producer<String, String> producer = new KafkaProducer<>(props);

props.put(“compression.type”, “gzip”)，它表明该 Producer 的压缩算法使用的是 GZIP。这样 Producer 启动后生产的每个消息集合都是经 GZIP 压缩过的，故而能很好地节省网络传输带宽以及 Kafka Broker 端的磁盘占用。

大部分情况下 Broker 从 Producer 端接收到消息后仅仅是原封不动地保存而不会对其进行任何修改，但是当broker端与producer端消息压缩格式不一致时，会解压后再重新压缩，还有Broker 端发生了消息格式转换也可能解压缩，这种情况通常是同时存在了v1、v2不同消息格式。这两种情况都会极大影响kafka性能，应该极力避免。

解压缩

通常解压缩发生在消费者程序中，压缩消息到 Broker 后，Broker 原样保存。当 Consumer 程序请求这部分消息时，由 Consumer 解压缩还原成之前的消息。

Consumer 怎么知道这些消息是用何种压缩算法压缩的呢？其实就在消息中，这样当 Consumer 读取到消息集合时，它就知道了这些消息使用的是哪种压缩算法。用一句话总结一下压缩和解压缩：Producer 端压缩、Broker 端保持、Consumer 端解压缩。

Broker 端也会进行解压缩。不过这和前面提到消息格式转换时是不同的场景。每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作，目的就是为了对消息执行各种验证。这种解压缩对 Broker 端性能是有一定影响的，特别是对 CPU 的使用率而言。

压缩算法对比

一个压缩算法的优劣，有两个重要的指标：一个是压缩比，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好；另一个就是压缩 / 解压缩吞吐量，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。

在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：GZIP、Snappy 和 LZ4。从 2.1.0 开始，Kafka 正式支持 Zstandard 算法（简写为 zstd）。它是 Facebook 开源的一个压缩算法，能够提供超高的压缩比（compression ratio）。

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

从表中我们可以发现 zstd 算法有着最高的压缩比，而在吞吐量上的表现只能说中规中矩。反观 LZ4 算法，它在吞吐量方面则是毫无疑问的执牛耳者。当然对于表格中数据的权威性我不做过多解读，只想用它来说明一下当前各种压缩算法的大致表现。

性能测试结果，吐量方：LZ4 > Snappy > zstd 和 GZIP；压缩比：zstd > LZ4 > GZIP > Snappy。具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比；在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。

最佳实践

我们可以根据以上算法就自身的实际情况有针对性地选择合适的压缩算法。

启用压缩的一个条件就是 Producer 的 CPU 资源很充足。如果 Producer 运行机器本身 CPU 已经消耗殆尽了，那么启用消息压缩只会适得其反。

如果带宽资源有限，也建议你开启压缩。带宽是比 CPU 和内存还要珍贵的稀缺资源，如果机器 CPU 资源有很多富余，开启压缩能极大地节省网络资源消耗。