Kafka 高并发设计之数据压缩与批量消息处理

《Kafka 高性能架构设计 7 大秘诀》专栏第 6 章。

压缩，是一种用时间换空间的 trade-off 思想，用 CPU 的时间去换磁盘或者网络 I/O 传输量，用较小的 CPU 开销来换取更具性价比的磁盘占用和更少的网络 I/O 传输。

Kafka 是一个高吞吐量、可扩展的分布式消息系统，深入掌握 Kafka 的数据压缩和批量数据处理机制，对于优化系统性能和资源使用至关重要。

Kafka 数据压缩机制

数据压缩在 Kafka 中有助于减少磁盘空间的使用和网络带宽的消耗，从而提升整体性能。

通过减少消息的大小，压缩可以显著降低生产者和消费者之间的数据传输时间。

Chaya：Kafka 支持的压缩算法有哪些？

在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：GZIP、Snappy 和 LZ4。从 2.1.0 开始，Kafka 正式支持 Zstandard 算法（简写为 zstd）。

Chaya：这么多压缩算法，我如何选择？

一个压缩算法的优劣，有两个重要的指标：压缩比，文件压缩前的大小与压缩后的大小之比，比如源文件占用 1000 M 内存，经过压缩后变成了 200 M，压缩比 = 1000 /200 = 5，压缩比越高越高；另一个指标是压缩/解压缩吞吐量，比如每秒能压缩或者解压缩多少 M 数据，吞吐量越高越好。

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

从图中可以看到，ZSTD 压缩比最高，但是吞吐量中规中矩。LZ4 在吞吐量方面属于王者。

• GZIP：压缩比高，但压缩和解压缩速度相对较慢。适用于对传输带宽要求较高的场景。

• Snappy：由 Google 开发，压缩和解压缩速度快，但压缩比相对较低。适用于对性能要求较高的场景。

• LZ4：在压缩和解压缩速度以及压缩比之间取得良好平衡。适用于对性能和压缩比有综合需求的场景。

• ZSTD：由 Facebook 开发，提供高压缩比和较快的压缩解压速度。适用于对高效压缩和快速处理都有需求的场景。

在 Kafka 的性能测试结果中，不同压缩算法的两个指标有以下排序特点。

• 吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；

• 压缩比方面：zstd > LZ4 > GZIP > Snappy。

何时压缩

Chaya：我觉得可以在生产者和 Broker 端进行压缩，对么？

在生产者端压缩是很自然的想法，大部分情况下 Broker 收到 Producer 端的消息后是原封不动的保存，并不会进行压缩。

生产者压缩

Kafka 的数据压缩主要在生产者端进行。具体步骤如下：

1. 生产者配置压缩方式：在 KafkaProducer 配置中设置 compression.type 参数，可以选择 gzip、snappy、lz4 或 zstd。

2. 消息压缩：生产者将消息批量收集到一个 batch 中，然后对整个 batch 进行压缩。这种批量压缩方式可以获得更高的压缩率。

3. 压缩消息存储：压缩后的 batch 以压缩格式存储在 Kafka 的主题（Topic）分区中。

4. 消费者解压缩：消费者从 Kafka 主题中获取消息时，首先对接收到的 batch 进行解压缩，然后处理其中的每一条消息。