一、kafka壓縮幾點說明
首先說明一點kafka的壓縮和kafka的compact是不同的桐绒，compact就是相同的key只保留一條，是數(shù)據(jù)清理方式的一種和kafka的定期刪除策略是并列的蚤蔓；而kafka的壓縮是指數(shù)據(jù)不刪除只是采用壓縮算法進行壓縮搏讶。
kafka從0.7版本就開始支持壓縮功能：
1）kafka的發(fā)送端將消息按照批量（如果批量設(shè)置一條或者很小洼畅，可能有相反的效果）的方式進行壓縮吩案。
2）服務(wù)器端直接將壓縮消息保存（特別注意，如果kafka的版本不同帝簇，那么就存在broker需要先解壓縮再壓縮的問題务热，導(dǎo)致消耗資源過多）。
3）消費端自動解壓縮己儒，測試了下，發(fā)送端無論采用什么壓縮模式捆毫，消費端無論設(shè)置什么解壓模式闪湾，都可以自動完成解壓縮功能。
4）壓縮消息可以和非壓縮消息混存绩卤，也就是說如果你kafka里面先保存的是非壓縮消息途样，后面改成壓縮江醇，不用擔心，kafka消費端自動支持何暇。
二陶夜、kafka壓縮算法種類和性能區(qū)別
測試的kafka版本：kafka_2.12-1.1.1
測試的kafka客戶端版本：0.10.2.1
測試數(shù)據(jù)的條數(shù)：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 |
測試遇到疑問宏胯，開始非壓縮算法發(fā)送2萬條大小為16MB羽嫡，后面再發(fā)送到gzip的時候大小竟然自動變成了8.2MB，采用的是delete模式肩袍，估計可能是日志之類的杭棵，snappy也有類似的現(xiàn)象開始是4.0MB，后面log大小縮小為3.2MB氛赐，有朋友知道麻煩告知魂爪。
我懷疑可能是版本原因?qū)е聰?shù)據(jù)重新被壓縮，1.1.1優(yōu)化的更好艰管，所以壓縮效果更好
通過上面數(shù)據(jù)來看滓侍，gzip的壓縮效果最好，但是生成耗時更長蛙婴，snappy和lz4的數(shù)據(jù)差不多粗井，更傾向于lz4，具huxi大神的書上所說kafka里面對snappy做了硬編碼街图，所以性能上最好的是lz4浇衬，推薦使用此壓縮算法。
壓縮率對比：
性能對比圖：
壓縮設(shè)置
很簡單：
/*compressType有四種取值:none lz4 gzip snappy*/
props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, compressType);
其他說明
消費端無論設(shè)置什么壓縮模式餐济，都可以正確的解壓kafka的消息耘擂，也就是說消費端可以不設(shè)置解壓縮，
不過可能性能有所下降絮姆。
