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 的数据压缩主要在生产者端进行。详细步骤如下：
  

• 生产者配置压缩方式：在 KafkaProducer 配置中设置 compression.type 参数，可以选择 gzip、snappy、lz4 或 zstd。
  
• 消息压缩：生产者将消息批量收集到一个 batch 中，然后对整个 batch 进行压缩。这种批量压缩方式可以得到更高的压缩率。
  
• 压缩消息存储：压缩后的 batch 以压缩格式存储在 Kafka 的主题（Topic）分区中。
  
• 消耗者解压缩：消耗者从 Kafka 主题中获取消息时，首先对接收到的 batch 进行解压缩，然后处置惩罚其中的每一条消息。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。