1.kafka压缩参数说明
compression.type:
producer用于压缩数据的压缩类型。默认是无压缩。正确的选项值是none、gzip、snappy和lz4。压缩最好用于批量处理，批量处理消息越多，压缩性能越好。推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。
kafka的压缩和kafka的compact是不同的，compact就是相同的key只保留一条，是数据清理方式的一种和kafka的定期删除策略是并列的；而kafka的压缩是指数据不删除只是采用压缩算法进行压缩。
kafka从0.7版本就开始支持压缩功能：
1）kafka的发送端将消息按照批量（如果批量设置一条或者很小，可能有相反的效果）的方式进行压缩。
2）服务器端直接将压缩消息保存（特别注意，如果kafka的版本不同，那么就存在broker需要先解压缩再压缩的问题，导致消耗资源过多）。
3）消费端自动解压缩，测试了下，发送端无论采用什么压缩模式，消费端无论设置什么解压模式，都可以自动完成解压缩功能。
4）压缩消息可以和非压缩消息混存，也就是说如果你kafka里面先保存的是非压缩消息，后面改成压缩，不用担心，kafka消费端自动支持。
也就是说：Producer 端压缩、Broker 端保持、Consumer 端解压缩。
2.kafka压缩算法样例
测试的kafka版本：kafka_2.10-0.10.2.2
测试的kafka客户端版本：0.10.2.1
测试数据的条数：20000
测试每条数据大小：40K
kafka支持五种压缩算法：none、lz4、snappy、gzip、ZStandard
注意：Apache Kafka 2.1.0正式支持ZStandard —— ZStandard是Facebook开源的压缩算法，官网说有长超高的压缩比(这里不进行测试此算法)
Topic | 压缩算法 | 大小 | 压缩比 | 生成耗时(毫秒) | 消费耗时(毫秒) |
Normal | none | 771M | 0 | 11.8026751s | 11.2436431s |
LZ4 | lz4 | 9.8M | 1.2% | 5.4113095s | 1.9171097s |
snappy | snappy | 77M | 9.98% | 4.8842794s | 1.8741072s |
gzip | gzip | 20M | 2.59% | 9.0055151s | 2.2701298s |
有疑问，开始非压缩算法none发送2万条大小为1124MB，发送完后过了几十秒大小竟然自动变成了771MB，采用的是delete模式，估计可能是日志之类的，snappy也有类似的现象开始是124MB，后面log大小缩小为77MB，还没有完全弄清楚什么原因。
可能是版本原因导致数据重新被压缩，1.1.1优化的更好，所以压缩效果更好。
结论：
算法对比：根据测试数据，lz4的压缩效果最好，生产耗时snappy和lz4的数据差不多，更倾向于lz4，网上说kafka里面对snappy做了硬编码，gzip的压缩和生产、消费耗时效果一般，所以性能上最好的是lz4，推荐使用lz4此压缩算法。
CPU方面: 生产端Snappy算法使用的CPU资源最多，其他3种压缩算法相差不多。
消费端4种种压缩算法的客户端CPU使用率基本持平
3.kafka消费端
生产端无论设置什么压缩模式，消费端都可以正确的解压kafka的消息，也就是说消费端可以不设置解压缩。
消费过程中消费压缩数据可能遇见的报错以及解决办法：
解决办法:
config.Version = sarama.V0_10_2_1 //换成对应的Kafka版本
