💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
# 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 ![](https://img.kancloud.cn/cf/e2/cfe20a2cdcb1ae3b304777f7be928068_411x346.png) ## 最佳实践 * Producer 端完成压缩 * 保障 Producer 机器上 CPU 资源充足 * 如果带宽有限,开启压缩