使用批量訊息提升服務端處理能力

在Kafka內部，訊息都是以“批”為單位處理的，Kafka的客戶端SDK在實作訊息發送邏輯的時候，采用了異步批量發送的機制，

當我們呼叫send()方法發送一條訊息后，無論我們是同步發送還是異步發送，Kafka并不會立刻把這條訊息發送出去，它會先把這條訊息存放在記憶體中，然后選擇合適的時機把快取的所有訊息組成一批，一次性的發給Broker，

在Broker端，整個處理流程中，無論是寫入磁盤、從磁盤讀出來、還是復制到其他副本，批訊息都不回被解開，一直是作為一條“批訊息”進行處理的，

在消費時，訊息同樣是以批為單位進行傳遞的，Consumer從Broker拉到一批訊息后，在客戶端把批訊息解開，再一條一條交給用戶代碼處理，

這樣，構建批訊息和解開批訊息分別在發送端和消費端的客戶端完成，不僅減輕了Broker的壓力，還減少了Broker處理請求的次數，提升了總體的處理能力，

使用順序讀寫提升磁盤IO性能

對于磁盤來說，一個重要特性是順序讀寫的性能要遠遠好于隨機讀寫，

Kafka利用了磁盤這個特性，它的存盤設計非常簡單，對于每個磁區，它把從Producer收到的訊息，順序地寫入對應的log檔案中，一個檔案寫完了，就開啟一個新的檔案繼續順序寫下去，消費的時候，也是從某個全域的位置開始，順序地把訊息讀出來，

Kafka會利用PageCache加速訊息讀寫，PageCache是作業系統在記憶體中給磁盤上的檔案建立的快取，無論我們使用什么語言撰寫的程式，在呼叫系統的API讀寫檔案的時候，并不會直接去寫磁盤上的檔案，應用程式實際操作的都是PageCache，也就是檔案在記憶體中快取的副本，

應用程式在寫入檔案的時候，作業系統會先把資料寫入到記憶體的PageCache，然后再一批一批地寫到磁盤上，

當我們從PageCache中讀物資料時，會有兩種結果：

PageCache中有資料，可以直接讀取，這樣就節省了從磁盤上讀物資料的時間，
PageCache中沒有資料，作業系統會引發一個缺頁中斷，應用程式的讀取執行緒被阻塞，作業系統把資料從檔案中復制到PageCache中，然后應用程式再從PageCache中繼續把資料讀出來，這時真正讀一次磁盤上的檔案，這個讀的程序會比較慢，

用戶的應用程式在使用完某塊PageCache后，作業系統并不會立刻就清除這個PageCache，而是盡可能的利用空閑的物理記憶體保存這些pageCache，除非系統記憶體不夠，作業系統才會清理掉一部分PageCache，清理策略一般是LRC或者它的變種方法，

在服務端，處理消費的邏輯步驟如下：

這個程序中，資料實際上做了2到3次復制：

Kafka使用零拷貝技術把上述復制次數減少一次，上面的第2步和第3步的兩次復制合并成一次復制，直接從PageCache中將資料復制到Socket緩沖區，這樣不僅減少了一次資料復制，而且由于不用把資料復制到用戶記憶體空間，DMA控制器就可以直接完成資料復制，不需要CPU參與，速度更快，

如果我們遇到這種從檔案讀出資料后再通過網路發送出去的場景，并且這個程序匯總你必須要對這些資料進行處理，那一定要使用零拷貝方法，可以有效提升性能，

　　　　作者：李潘　　　　出處：http://wing011203.cnblogs.com/ 　　　　本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/547115.html