Kafka 关于压缩的一点经验

前言

就压缩而言，对于数据储存应该是一个比较大的优化， 而 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的服务器上执行多个快速压缩算法测试获取的结果。

压缩算法对比

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