# Consumer 壓縮算法 壓縮（Compression）的思想 * 時間換空間的 trade-off 思想 ## 壓縮 Kafka 有兩類消息格式 * 社區版本稱之為 V1 & V2 * V2 是在 Kafka 0.11.0.0 引入 Kafka 消息層次 * 消息集合（Message set） * 消息集合中包含若干條日志項（record item） * 日志項：真正封裝消息 * 消息（Message） * Kafka 底層的消息日志由一系列消息集合日志項組成 * Kafka 在消息集合層面上進行寫入操作 V2 的目的 * 把消息的公共部分抽取放到外層消息集合，而不用每條消息都保存 * e.g. CRC 校驗：從 V1 版本對于每個消息的校驗 -> V2 版本對消息集合的校驗 * 壓縮方法改變 * V1 壓縮方法：多條消息進行壓縮然后保存到外層消息體字段中 * V2 壓縮方法：對整個消息集合進行壓縮 * V2 壓縮更有效率 ## 何時壓縮？ 壓縮發生的位置 * Producer * Producer 中配置 compression.type 即啟用指定類型的壓縮算法 * 常規會在 Producer 對消息進行壓縮 * Broker * 有兩種情況需要 Broker 重新壓縮 * Broker 指定了和 Producer 不同的壓縮算法 * 這種情況會導致 Broker CPU 使用率飆升 * Broker 發生了消息格式轉換 * 主要是兼容老版本的 Consumer * 這種情況會喪失 zero-copy 特性 ## 何時解壓縮？ * 通常發生在 Consumer 端，Consumer 自行解壓縮 * Kafka 會將啟用了哪種壓縮算法封裝進消息集合中 ### 總結 * Producer 端壓縮 * Broker 端保持 / 解壓縮&壓縮 * Consumer 端解壓縮 ## 壓縮算法對比 * Kafka 2.1.0 版本之前 * GZIP * Snappy * LZ4 * 從 2.1.0 開始 * zstd（i.e. Zstandard） * Facebook 開源，具有超高壓縮比 * 吞吐量 * LZ4 > Snappy > zstd = GZIP * 壓縮比 * zstd > LZ4 > GZIP > Snappy ### 壓縮算法評價指標 * 壓縮比（compression ratio）：原先占用空間 / 壓縮后空間 * 壓縮 / 解壓縮吞吐量，i.e. 每秒壓縮、解壓縮多少 MB  ## 最佳實踐 * Producer 端完成壓縮 * 保障 Producer 機器上 CPU 資源充足 * 如果帶寬有限，開啟壓縮