前言

就压缩而言，对于数据储存应该是一个比较大的优化，
而 Kafka 自然也是支持这种特性的，
但是这里可能会有那么一点坑。
我们主要从：

1. 何时产生压缩？
2. 何时会解压缩？

两个方面来说，并针对一些可能出现的坑做一些说明。

何时产生压缩

1. 生产者
   为了数据在传输到 Kafka 可以更快，
   那么在生产者启动压缩自然是很正常的。
2. Broker端
   Broker 主要是负责储存数据，
   压缩能够很好的减少磁盘的占用。
   一般情况而言，
   如果数据已经在 生产者端压缩了，
   那么其实就不需要在Broker端再做处理，
   实际上也确实是这样，
   但是如果发生以下这些情况，
   那么Broker端会再进行压缩，
   这样无疑会导致性能问题，
   所以应该尽量避免：
   • Broker端指定了和Producer端不同的压缩算法，
     这很好理解，因为压缩算法不一致，
     Broker 就需要解压缩，并在此压缩成设定好的算法，
     所以一定要避免这种情况。
   • Broker端发生了消息格式转换。
     这里所谓的消息格式转换，是因为在Kafka更新的过程中，进行了一次消息格式的修改，
     如果生产者 和 Kafka 集群版本的消息格式不一致，
     那么 Broker端为了兼容考虑，
     会将 生产者的消息格式修改为当前版本的消息格式，
     而转换消息格式是必然涉及 解压缩 和 重压缩的，

何时解压缩？

1. Consumer端
   消费数据自然需要将数据解压缩，这个没什么好说的。

2. Broker端
   这里可能你要奇怪了，
   为什么Broker端还要解压缩呢？
   实际上Broker端只是为了进行消息的校检，
   以保证数据的正确性，
   这样必然会给Broker端的性能带来一定的影响，
   但是就目前来说，好像也没什么好的解决办法。

最后 附上一张压缩算法对比图
使用lzbench （一种开源内存基准测试工具）在运行Linux Debian的服务器上执行多个快速压缩算法测试获取的结果。

压缩算法对比.jpg

OK！就这样吧....嘿嘿~~~希望对你有一点帮助！！！