一、kafka压缩几点说明
首先说明一点kafka的压缩和kafka的compact是不同的，compact就是相同的key只保留一条，是数据清理方式的一种和kafka的定期删除策略是并列的；而kafka的压缩是指数据不删除只是采用压缩算法进行压缩。
kafka从0.7版本就开始支持压缩功能：
1）kafka的发送端将消息按照批量（如果批量设置一条或者很小，可能有相反的效果）的方式进行压缩。
2）服务器端直接将压缩消息保存（特别注意，如果kafka的版本不同，那么就存在broker需要先解压缩再压缩的问题，导致消耗资源过多）。
3）消费端自动解压缩，测试了下，发送端无论采用什么压缩模式，消费端无论设置什么解压模式，都可以自动完成解压缩功能。
4）压缩消息可以和非压缩消息混存，也就是说如果你kafka里面先保存的是非压缩消息，后面改成压缩，不用担心，kafka消费端自动支持。
二、kafka压缩算法种类和性能区别
测试的kafka版本：kafka_2.12-1.1.1
测试的kafka客户端版本：0.10.2.1
测试数据的条数：20000
kafka支持三种压缩算法，lz4、snappy、gzip，
| 压缩算法 | 大小 | 压缩比 | 生成耗时（毫秒） | 消费耗时（毫秒） |
|---|---|---|---|---|
| None | 8.2MB | 0 | 4739 | 17464 |
| gzip | 1.9 MB | 23% | 4684 | 16257 |
| snappy | 3.2 MB | 39% | 3936 | 16726 |
| lz4 | 2.9 MB | 35% | 3723 | 17229 |
测试遇到疑问，开始非压缩算法发送2万条大小为16MB，后面再发送到gzip的时候大小竟然自动变成了8.2MB，采用的是delete模式，估计可能是日志之类的，snappy也有类似的现象开始是4.0MB，后面log大小缩小为3.2MB，有朋友知道麻烦告知。
我怀疑可能是版本原因导致数据重新被压缩，1.1.1优化的更好，所以压缩效果更好
通过上面数据来看，gzip的压缩效果最好，但是生成耗时更长，snappy和lz4的数据差不多，更倾向于lz4，具huxi大神的书上所说kafka里面对snappy做了硬编码，所以性能上最好的是lz4，推荐使用此压缩算法。
压缩率对比：
性能对比图：
压缩设置
很简单：
/*compressType有四种取值:none lz4 gzip snappy*/
props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, compressType);
其他说明
消费端无论设置什么压缩模式，都可以正确的解压kafka的消息，也就是说消费端可以不设置解压缩，
不过可能性能有所下降。
