Golang学习篇—kafka客户端压缩

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版本