Kafka 会为我们保留一定量时间的数据那么为Kafka 选择一个合适的压缩算法是非常重要的,可以在节约存储空间的同时又将效率影响到最低。
在 Kafka 中，压缩可能发生在两个地方：生产者端和 Broker 端。
生产者程序中配置 compression.type 参数即表示启用指定类型的压缩算法。比如下面这段程序代码展示了如何构建一个开启 GZIP 的 Producer 对象：
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"
props.put("compression.type", "gzip");
Producer<String, String> producer = new KafkaProducer<>(props);
这里比较关键的代码行是 props.put(“compression.type”, “gzip”)，它表明该Producer 的压缩算法使用的是 GZIP。这样 Producer 启动后生产的每个消息集合都是经GZIP 压缩过的，故而能很好地节省网络传输带宽以及 Kafka Broker 端的磁盘占用。
在生产者端启用压缩是很自然的想法，那为什么我说在 Broker 端也可能进行压缩呢？其实大部分情况下 Broker 从 Producer 端接收到消息后仅仅是原封不动地保存而不会对其进行任何修改，但这里的“大部分情况”也是要满足一定条件的。但是也有例外情况就可能让Broker 重新压缩消息。
默认情况下broker 是遵循生产者的压缩算法的，但是也可以直接指定。假设生产者的压缩算法是gzip, 和broker的压缩是snappy 那么就好玩了。只能解压缩然后使用 Snappy 重新压缩一遍。通常表现为 Broker 端 CPU 使用率飙升。
有压缩必有解压缩！通常来说解压缩发生在消费者程序中，那么现在问题来了，Consumer 怎么知道这些消息是用何种压缩算法压缩的呢？其实答案就在消息中。Kafka 会将启用了哪种压缩算法封装进消息集合中，这样当 Consumer 读取
到消息集合时，它自然就知道了这些消息使用的是哪种压缩算法。如果用一句话总结一下压缩和解压缩：Producer 端压缩、Broker 端保持、Consumer端解压缩。
当然还有broker 也会执行解压缩，包含上面的情况压缩格式不一致，也会出现解压缩。但是还有解压缩发生在broker不是刚刚说到的压缩格式不一致的问题。每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作，目的就是为了对消息执行各种验证。我们必须承认这种解压缩对 Broker 端性能是有一定影响的，特别是对 CPU 的使用率而言。
有位小伙伴就在开源社区上面提到了这个问题https://issues.apache.org/jira/browse/KAFKA-8106 去掉在broker去掉对消息的解压缩验证，目前看到jira 已经修复了，看来规避了broker端为执行校验而做的解压缩操作，代码也merge进了2.4版本。
文末给出一个Facebook Zstandard 官网提供的一份压缩算法 benchmark 比较结果 仅作选在压缩算法上的一个参考 ：
最重要还是要根据实际的集群的带宽，磁盘，cpu等资源合理选择
