说到压缩第一个问题一定是 Kafka 在哪里进行压缩又是在哪里进行解压的我不卖关子直接告诉你答案Kafka 通常在 Producer 端进行压缩在 Broker 端保持到了 Consumer 端解压。除了 Producer 端压缩之外Broker 端也是可以进行压缩的但这种情况并不常见。具体情况我们在下一节再聊。在 Producer 端开启压缩的方法也很简单我们在设置 Producer 属性时增加compression.type参数即可例如我们在 Producer 端启用 gzip 压缩就可以这样设置props.put(compression.type, gzip);在 Kafka 中压缩并不是针对单条消息而是针对一个批次那么如何才能提高压缩的效率呢答案是增大批次的大小。因为压缩的本质是通过找到数据之间的重复模式来减少体积批次内积累的数据越多重复的可能性就越大压缩概率也就越好。因此我们在启用压缩之后还需要合理的设置batch.size和linger.ms这两个参数。重压缩前面我们提到了 Kafka Broker 端也可以进行压缩但只有在少数几种场景下才会出现因为 Kafka 的设计初衷是 Broker 端尽量只做简单的磁盘读写操作。由于 Broker 端进行压缩需要先把数据解压然后进行处理再压缩。我们把这一过程称为重压缩。重压缩主要出现在以下三种场景场景一压缩算法不一致例如 Producer 端使用了 gzip 算法但 Broker 端配置了compression.typelz4这种情况 Broker 必须进行重压缩。场景二消息格式版本转换Kafka 在 0.11.0.0 版本进行了一次消息格式版本的升级新版本的消息会统一存储消息批次的公共信息。如果你的 Producer 版本是旧版本Broker 是新版本那么 Broker 就需要进行消息格式转换。这一操作也要涉及到重压缩。场景三Broker 侧注入时间戳Kafka 支持两种时间戳一种是 CreateTime在 Producer 端直接设置。另一种是 LogAppendTime这种时间戳是记录的 Broker 在写入磁盘时的时间戳Broker 需要解压整个批次然后修改每条消息的时间戳再压缩整个批次。时间戳的配置参数是log.message.timestamp.type我们保持默认的 CreateTime 就好。最后再提一下重压缩是非常消耗 Broker 端 CPU 资源的我们要尽量避免 Broker 端的重压缩让它只做磁盘的读写操作就好。如果有 Broker 端 CPU 资源飙升的问题也可以按照以上三种场景排查一下是不是重压缩引起的。压缩算法Kafka 支持了多种压缩算法选择合适的压缩算法其实是在压缩率与 CPU 开销之间做出平衡。我们通过一个表格来对比一下几种压缩算法。算法压缩率CPU消耗压缩速度适用场景GZIP高高慢存储敏感带宽受限的归档、离线处理Snappy中等较低快速度与资源之间取得良好平衡LZ4中等偏高极低极快对延迟极度敏感的实时计算、交易等Zstd高与 GZIP 接近中等较快适合大部分通用场景总的来说4 种算法在实际使用过程中各有千秋Zstd 是 Kafka 2.1.0 版本引入的作为现代均衡的算法可以作为默认选择。如果想要追求吞吐量可以选择 LZ4。想要追求极致资源节省可以选择 GZIP 或者 Zstd。总结最后总结一下本文的内容我们先介绍了怎么 Kafka 在哪里进行压缩的以及如何开启压缩。接着又介绍了 3 种重压缩的场景重压缩大概率会导致 Broker CPU 飙升。最后对比了 Kafka 支持的 4 种压缩算法。