kafka使用資料壓縮，最高可提公升約幾十倍吞吐量。資料壓縮不僅可節省儲存空間，還可用於提公升網路傳輸效能。這種使用壓縮提公升系統效能的方法，不僅在mq使用，日常開發也可。比如傳輸大量資料或要在磁碟、資料庫中儲存較大資料，這些情況下，都可考慮使用資料壓縮提公升效能，還能節省網路頻寬和儲存空間。
程序間通過網路傳輸資料是不是需要壓縮？
壓縮和解壓的操作都是計算密集型操作。如果你的應用處理業務邏輯就需耗費大量cpu資源，就不太適合再壓縮解壓。
若系統瓶頸是磁碟io效能，cpu資源又閒，這就非常適合在把資料寫入磁碟前先壓縮。
但若系統讀寫比嚴重失調，要考慮每讀次資料就解壓次是不是划算。
壓縮的本質是資源置換，即時間換空間或cpu資源換儲存資源。
就像木桶理論，每個系統都有效能瓶頸資源，可能磁碟io、網路頻寬、cpu。
若使用壓縮，能用長板來換些短板，那總體上就能提公升效能，這就划算。
若用壓縮後，短板更短，就不划算。
只有通過效能測試，確認資料壓縮可提公升系統效能，就需選擇合適壓縮演算法了。
壓縮演算法可以分為
無失真壓縮
這討論都是無失真壓縮，即資料經過壓縮和解壓過程後，與壓縮前相比100%相同。
資料為什麼可被壓縮呢？各種各樣壓縮演算法又怎麼壓縮資料的？
舉個極端例子：
0000000000000000000020個0壓縮樣本對壓縮速度和壓縮比的影響也較大，同樣大小的一段數字和一段新聞的文字，即使用相同壓縮演算法，壓縮率和壓縮時間差異也較大。
所以，有時在選擇壓縮演算法前，用系統樣例業務資料做個測試，幫你找到最合適壓縮演算法。
如果感興趣，可學習最經典的壓縮演算法：哈夫曼編碼。大部分壓縮演算法區別主要是，對資料進行編碼的演算法，壓縮的流程和壓縮包的結構大致一樣。
而在壓縮過程中，你最需要了解的就是如何選擇合適的壓縮分段。
壓縮時，給定的被壓縮資料它必須有確定長度，或是有頭有尾的，不能是個無限資料流，若要對流資料壓縮，必須把流資料劃分成多幀，一幀幀分段壓縮。
主要因為壓縮演算法在壓縮前，一般都需對被壓縮資料從頭到尾掃瞄：確定如何對資料劃分和編碼。
被壓縮資料長度越大，重位元速率更高，壓縮比也越高。
比如這篇文章，可能出現幾十次「壓縮」，將整篇文章壓縮，這詞重複率幾十次，但按照每個自然段來壓縮，每段中這詞重複率只有二三次。顯然全文壓縮壓縮率高於分段壓縮。
分段並非越大越好，超過一定長度後，再增加長度對壓縮率貢獻不大了。
過大的分段長度在解壓時，還有更多解壓浪費。
比如，乙個1mb大小的壓縮檔案，即使你只是需要讀其中很短的幾個位元組，也不得不把整個檔案全部解壓縮，造成很大的解壓浪費。
所以要根據業務，選擇合適壓縮分段，在壓縮率、壓縮速度、解壓浪費間找到平衡點。
確定資料劃分和壓縮演算法後，就可壓縮了，壓縮過程就是用編碼替換原始資料。
壓縮後的壓縮包是由這編碼字典和用編碼替換後的資料組成。
這就是資料壓縮過程。解壓時，先讀取編碼字典，然後按字典把壓縮編碼還原成原始資料即可。
首先可以配置kafka是否開啟壓縮，支援配置使用哪種壓縮演算法。
因為不同場景是否需要開啟壓縮，選擇哪種壓縮演算法都不能一概而論。
所以kafka將選擇權交給使用者。
在開啟壓縮時，kafka選擇一批訊息一起壓縮，每乙個批訊息就是乙個壓縮分段。使用者也可以通過引數來控制每批訊息的大小。
在kafka中，生產者生成乙個批訊息發給服務端，在服務端中是不會拆分批訊息的。那按批壓縮，意味在服務端也不用對這批訊息進行解壓，可整批直接儲存，然後整批發給消費者。最後，批訊息由消費者解壓。
在服務端不用解壓，就不會耗費服務端cpu，同時還能獲得壓縮後，占用傳輸頻寬小，占用儲存空間小。
使用kafka時，如果生產者和消費者的cpu不是特別吃緊，開啟壓縮後，可節省網路頻寬和服務端的儲存空間，提公升總體的吞吐量，一般都是個不錯的選擇。
kafka在生產者上，對每批訊息進行壓縮，批訊息在服務端不解壓，消費者在收到訊息之後再進行解壓。kafka的壓縮和解壓都是在客戶端完成的。
壓縮演算法是zip，預設級別5（可配置）
也是客戶端做解壓縮工作，服務端只儲存。
private
boolean
trytocompressmessage
(final message msg)
byte
body = msg.
getbody()
;if(body != null)
}catch
(ioexception e)}}
return
false
;}
資料壓縮本質是cpu資源換儲存資源，或用壓縮解壓的時間換取儲存的空間。
在選擇壓縮演算法的時候，需綜合考慮壓縮時間和壓縮率兩個因素，被壓縮資料的內容也是影響壓縮時間和壓縮率的重要因素。
必要時可先用業務資料做乙個壓縮測試，這樣有助於選擇最合適的壓縮演算法。
另外影響壓縮率的重要因素是壓縮分段，需根據業務情況選擇乙個合適分段，在保證壓縮率前提下，儘量減少解壓浪費。
春招面試小記
前記 我本來是想來把c 的博補上的，又耽誤了一天，我的鍋，雖然確實是有事但是不找藉口，之後我會努力調節自己，按照計畫執行 ps 昨天是乙個極點，前幾天打了雞血一樣忙得腳不著地，但是依然不覺得累，昨天基本除了面試還有調了下 基本沒乾啥，但是特別疲倦，今天起來果然精神恢復了些了，加油 正文 昨天是學校的...
linux 訊息佇列 （複習
複習中，心裡沒底.小悲.程序管理之訊息佇列 檢視ipc物件命令主要有 ipcs m 檢視共享記憶體 ipcs q 檢視訊息佇列 ipcs s 檢視訊號量 ipc物件的操作，如刪除 ipcrm q id號 建立乙個訊息佇列 include include include include include...
華為 2020屆春招面試
華為的情況就不多介紹了，應該沒有人不知道，現在公司面臨制裁公司也有一些調整。總體上華為涉及的行業非常多，從自己的老本行通訊業務到大家熟悉的手機 平板，到近幾年興起的雲 車載相關，再到大家不熟悉的軍工 空調 電調反正什麼都做。做嵌入式的同學在這裡還是有非常多機會的。當時面試的部門還是屬於消費者bg的，...