# 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 资源充足 * 如果带宽有限，开启压缩