Kafka 支持的壓縮算法還挺多的，這一篇來站在Kafka的角度看一下壓縮算法秉剑。就當(dāng)前情況來說泛豪，支持GZIP、Snappy、LZ4 這三種壓縮算法诡曙。具體是通過compression.type 來開啟消息壓縮并且設(shè)定具體的壓縮算法臀叙。
props.put(“compressions.type”, “GZIP”);
或者
props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, “GZIP”)
壓縮算法是要占用挺大一部分cpu資源的并且耗時(shí)也是不小的，而壓縮的目的很大程度上是為了提升網(wǎng)絡(luò)傳輸?shù)男阅芗勐保吘剐↑c(diǎn)傳得快嘛劝萤。但是整個(gè)壓縮的過程也是很耗時(shí)的，通常來說KafkaProducer.send( )主要時(shí)間其實(shí)都花在在壓縮操作上荠雕，如果壓縮的過程十分漫長稳其，那么壓縮就顯得有點(diǎn)多余了，所以選擇一個(gè)高性能的壓縮算法是十分關(guān)鍵的炸卑。而且就現(xiàn)狀來說對于Kafka這種消息系統(tǒng)瓶頸往往不是CPU既鞠，通常來說都是受網(wǎng)絡(luò)帶寬。
下面來看看GZIP盖文、Snappy嘱蛋、LZ4 這三種壓縮算法
GZIP
GZIP是GNUzip的縮寫，最初是用于UNIX系統(tǒng)的文件壓縮五续，常見的.gz的壓縮文件就是gzip所壓縮得到的洒敏，通常來說，對于純文本內(nèi)容疙驾，可以壓縮到原大小的40%來進(jìn)行傳輸凶伙，Java 實(shí)現(xiàn)的gzip 和 unix下的gzip 壓縮效率和壓縮率是很相近的。
Snappy
Snappy是谷歌開源的一個(gè)壓縮/解壓庫它碎，其實(shí)Snappy的壓縮率挺一般的函荣，可能比我們常見的壓縮算法壓縮率都要差，但是Snappy 對于Kafka 這種消息系統(tǒng)來說有一個(gè)顯著的優(yōu)點(diǎn)扳肛，它的壓縮速率基本上是第一的傻挂。最初的設(shè)計(jì)目的就是用來平衡壓縮時(shí)間與壓縮率的的蒿辙，對于一些常規(guī)的文件平窘，多那么1、2 k但是要多花那么幾毫秒折剃，其實(shí)還挺得不償失的套腹，在Snappy最初推出的時(shí)候所重點(diǎn)宣傳的其實(shí)就是壓縮速率而非壓縮率绪抛。
LZ4
LZ4其實(shí)和snappy的初衷是相同的，但是LZ4追求壓縮速率的同時(shí)相對于snappy來說电禀，不僅壓縮更快了睦疫，壓縮率也更佳可觀了，同樣是谷歌開發(fā)的鞭呕。去看LZ4相關(guān)介紹的時(shí)候，提到了LZ77，博主是這么介紹LZ4的：LZ4就是一個(gè)用16k大小哈希表儲存字典并簡化檢索的LZ77葫松，而LZ77是一個(gè)應(yīng)用了字典來進(jìn)行壓縮的算法瓦糕。通俗來說，就是讓程序觀察（看字典）當(dāng)前看到的數(shù)據(jù)是否和之前有重復(fù)腋么， 如果有的話咕娄，我們就保存兩個(gè)重復(fù)字段的距離（offset）和重復(fù)的長度，以替代重復(fù)的字段而以此來壓縮數(shù)據(jù)珊擂。
其中LZ77 最大的缺陷是在字典中尋找待匹配的最長的字符串占用了大量的時(shí)間圣勒，如果字典和待搜索的緩存過短，能匹配到的概率就會非常小摧扇，針對這個(gè)問題LZ4做出了自己的改進(jìn)圣贸，從而進(jìn)一步的提升了壓縮速率。
因?yàn)槲覍嚎s算法也不是很熟悉扛稽，只能概要的介紹一下吁峻，推給大家，還請見諒在张，以后有機(jī)會仔細(xì)的來看這些壓縮算法用含，下面是幾種算法的一個(gè)比較，然后Kafka是按照batch對消息進(jìn)行壓縮的帮匾。
然后接下來Hash算法啄骇，Hash算法在Kafka 中被用來作為具體的分區(qū)選擇，這決定分區(qū)的選擇是否公平瘟斜、分配到的各個(gè)分區(qū)的消息和請求書是夠均衡缸夹。
Kafka 中使用的Hash算法叫做murmur2，murmurHash是一種比較先進(jìn)的非加密Hash算法（主要還是用來Kafka這種選擇的場景）哼转，當(dāng)前最新的版本是murmur3明未，它能在有規(guī)律的輸入時(shí)也能保證分布較為均勻，使用這個(gè)算法的還有redis（當(dāng)字典被用作數(shù)據(jù)庫的底層實(shí)現(xiàn)或者h(yuǎn)ash鍵的底層實(shí)現(xiàn)時(shí)壹蔓，來計(jì)算鍵的哈希值）趟妥、nginx、Hadoop佣蓉。然后說到Hash披摄，Java 中最常見的HashMap 采用的xors hash。
我們經(jīng)常在一些場景中聽到加密Hash 或者 不加密Hash這樣的一些詞兒勇凭，有時(shí)候感覺一些Hash散列算法就是加密疚膊，其實(shí)這方面是存在一些界限的。準(zhǔn)確來說Hash算法是一種消息摘要算法虾标，不是一種加密算法寓盗，但是因?yàn)镠ash算法的單向運(yùn)算（存在一定程度上的不可逆性），所以經(jīng)常被用來作為加密算法中的一個(gè)重要構(gòu)成部分，但是完整的加密算法遠(yuǎn)不止Hash算法（通常來說傀蚌，加密算法是可逆的）基显，除了加密算法，Hash本身最適合的場景其實(shí)是HashMap善炫、Kafka分區(qū)選擇這種選擇的場景撩幽。
這一篇說了一些概念和個(gè)人的見解，不是很熟悉箩艺，見諒窜醉。
