[文档修改](master): 生产者压缩算法面面观

周日学习 2022年09月18日00:15:52

bigdata/kafka/README.md

@@ -331,8 +331,91 @@ kafka-consumer-groups.sh --bootstrap-server 172.16.26.183:9092 --describe --grou
     - 使用这个方法：consumer.assign()直接消息指定分区
 
 ### 2.2 生产者压缩算法面面观
+- 说起压缩（compression），我相信你一定不会感到陌生。它秉承了**用时间去换空间的经典 trade-off 思想**，具体来说就是用 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 **通常不会直接操作具体的一条条消息，它总是在消息集合这个层面上进行写入操作**。
+  - V2 版本主要是针对 V1 版本的一些弊端做了修正
+    - 一个，就是把消息的公共部分抽取出来放到外层消息集合里面，这样就不用每条消息都保存这些信息了。
+      - 在 V2 版本中，消息的 CRC 校验工作就被移到了消息集合这一层。
+    - V2 版本还有一个和压缩息息相关的改进，就是保存压缩消息的方法发生了变化。
+      - 之前 V1 版本中保存压缩消息的方法是把多条消息进行压缩然后保存到外层消息的消息体字段中；而 V2 版本的做法是对整个消息集合进行压缩。显然后者应该比前者有更好的压缩效果。
+    - V2 版本都比 V1 版本节省磁盘空间。
+
+- 何时压缩？
+  - 在 Kafka 中，压缩可能发生在两个地方：生产者端和 Broker 端。
+- 生产者程序中配置 compression.type 参数即表示启用指定类型的压缩算法。
+- 下面这段程序代码展示了如何构建一个开启 GZIP 的 Producer 对象：
+```java
+ 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 端也可能进行压缩呢？其实大部分情况下 **Broker 从 Producer 端接收到消息后仅仅是原封不动地保存而不会对其进行任何修改**，但这里的“大部分情况”也是要满足一定条件的。
+- 有两种例外情况就可能让 Broker 重新压缩消息。
+  - 情况一：Broker 端指定了和 Producer 端不同的压缩算法。
+    - Producer 说：“我要使用 GZIP 进行压缩。”
+    - Broker 说：“不好意思，我这边接收的消息必须使用 Snappy 算法进行压缩。”
+    - Kafka 官网，你会发现 Broker 端也有一个参数叫 compression.type，和上面那个例子中的同名。但是这个**参数的默认值是 producer**，这表示 Broker 端会“尊重”Producer 端使用的压缩算法。
+      可一旦你在 Broker 端设置了不同的 compression.type 值，就一定要小心了，因为可能会发生预料之外的压缩 / 解压缩操作，**通常表现为 Broker 端 CPU 使用率飙升**。
+  - 情况二：Broker 端发生了消息格式转换。
+    - 在一个生产环境中，Kafka 集群中同时保存多种版本的消息格式非常常见。为了兼容老版本的格式，Broker 端会对新版本消息执行向老版本格式的转换。这个过程中会涉及消息的解压缩和重新压缩。一般情况下这种消息格式转换对性能是有很大影响的，除了这里的压缩之外，
+      它还让 Kafka 丧失了引以为豪的 Zero Copy 特性。
+  - 所以尽量保证消息格式的统一吧，这样不仅可以避免不必要的解压缩 / 重新压缩，对提升其他方面的性能也大有裨益。如果有兴趣你可以深入地了解下 Zero Copy 的原理。
+
+- 何时解压缩？
+  - 通常来说解压缩发生在消费者程序中，也就是说 Producer 发送压缩消息到 Broker 后，Broker 照单全收并原样保存起来。当 Consumer 程序请求这部分消息时，Broker 依然原样发送出去，**当消息到达 Consumer 端后，由 Consumer 自行解压缩还原成之前的消息**。
+  - Consumer 怎么知道这些消息是用何种压缩算法压缩的呢？其实答案就在消息中。**Kafka 会将启用了哪种压缩算法封装进消息集合中**，这样当 Consumer 读取到消息集合时，它自然就知道了这些消息使用的是哪种压缩算法。
+  - 住这句话：**Producer 端压缩、Broker 端保持、Consumer 端解压缩。**
+  - 除了在 Consumer 端解压缩，Broker 端也会进行解压缩。注意了，这和前面提到消息格式转换时发生的解压缩是不同的场景。每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作，**目的就是为了对消息执行各种验证**。
+    我们必须承认**这种解压缩对 Broker 端性能是有一定影响的，特别是对 CPU 的使用率而言**。
+  - 国内京东的小伙伴们刚刚向社区提出了一个 bugfix，建议去掉因为做消息校验而引入的解压缩。据他们称，**去掉了解压缩之后，Broker 端的 CPU 使用率至少降低了 50%**。
+    - 目前社区并未采纳这个建议，原因就是这种消息校验是非常重要的，不可盲目去之。毕竟先把事情做对是最重要的，**在做对的基础上，再考虑把事情做好做快**。
+    - 你也可以思考一下，是否有一个两全其美的方案，既能避免消息解压缩也能对消息执行校验。
+
+- 各种压缩算法对比
+  - 在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：**GZIP、Snappy 和 LZ4**。从 2.1.0 开始，Kafka 正式支持 **Zstandard** 算法（简写为 zstd）。它是 Facebook 开源的一个压缩算法，能够提供超高的压缩比（compression ratio）。
+  - 对了，看一个压缩算法的优劣，有两个重要的指标：
+    - 一个指标是**压缩比**，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好；
+    - 另一个指标就是**压缩 / 解压缩吞吐量**，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。
+    - Facebook Zstandard 官网提供的一份压缩算法 benchmark 比较结果：
+    - ![Zstandard压缩算法对比](pic/Zstandard压缩算法对比.png)
+      - zstd 算法有着最高的压缩比，而在吞吐量上的表现只能说中规中矩。
+      - 反观 LZ4 算法，它在吞吐量方面则是毫无疑问的执牛耳者。
+  - 在实际使用中，GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。
+  - 但对于 Kafka 而言，它们的性能测试结果却出奇得一致，
+    - 即**在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP**；
+    - 而**在压缩比方面，zstd > LZ4 > GZIP > Snappy**。
+    - 具体到**物理资源**，使用 **Snappy 算法占用的网络带宽最多，zstd 最少**，这是合理的，毕竟 zstd 就是要提供超高的压缩比；
+    - 在 **CPU 使用率**方面，各个算法表现得差不多，**只是在压缩时 Snappy 算法使用的 CPU 较多一些**
+    - 而**在解压缩时 GZIP 算法则可能使用更多的 CPU**。
+  - 最佳实践
+    - 首先来说压缩。何时启用压缩是比较合适的时机呢？
+      - 你现在已经知道 Producer 端完成的压缩，那么启用压缩的一个条件就是 **Producer 程序运行机器上的 CPU 资源要很充足**。如果 Producer 运行机器本身 CPU 已经消耗殆尽了，那么启用消息压缩无疑是雪上加霜，只会适得其反。
+      - 除了 CPU 资源充足这一条件，如果你的环境中带宽资源有限，那么我也建议你开启压缩。
+      - 事实上我见过的很多 Kafka 生产环境都遭遇过带宽被打满的情况。这年头，**带宽可是比 CPU 和内存还要珍贵的稀缺资源**，毕竟万兆网络还不是普通公司的标配，因此千兆网络中 Kafka 集群带宽资源耗尽这件事情就特别容易出现。
+      - **如果你的客户端机器 CPU 资源有很多富余，我强烈建议你开启 zstd 压缩，这样能极大地节省网络资源消耗**。
+    - 其次说说解压缩。其实也没什么可说的。
+      - 一旦启用压缩，解压缩是不可避免的事情。
+      - 这里只想强调一点：我们对不可抗拒的解压缩无能为力，但至少能规避掉那些意料之外的解压缩。就像我前面说的，因为要兼容老版本而引入的解压缩操作就属于这类。有条件的话尽量保证不要出现消息格式转换的情况。
 
-
+- 补充问题
+  - 正常情况下broker端会原样保存起来，但是为了检验需要解压缩。该怎么去理解这个过程呢，broker端解压缩以后还会压缩还原吗？
+    - 它只是解压缩读取而已，不会将解压缩之后的数据回写到磁盘。另外就像我置顶的留言那样，目前社区已经接纳了京东小伙伴的修改，貌似可以绕过这部分解压缩了.
+    - 规避了broker端为执行校验而做的解压缩操作，代码也merge进了2.4版本。有兴趣的同学可以看一下：
+      - https://issues.apache.org/jira/browse/KAFKA-8106
+  - 消息层次、消息集合、消息、日志项这些概念与它们之间的关系
+    - 消息批次RecordBatch里面包含若干条消息（record)。 你可以认为消息批次和消息集合是等价的，消息和日志项是等价的。这样消息层次有两层：外层是消息批次（或消息集合）；里层是消息（或日志项）。
+      Producer以recordbatch为单位发送消息，对于V2版本一个batch中通常包含多条消息。在V2版本中，在batch层面计算CRC值；在V1版本中，每条消息都要计算CRC值。