目錄

1、客戶端與服務端的互動

2、頻繁網路通訊帶來的效能低下問題

3、batch機制：多條訊息打包成一個batch

4、request機制：多個batch打包成一個request

“ 這篇文章，給大家聊一個訊息中介軟體相關的技術話題，對於一個優秀的訊息中介軟體而言，客戶端與服務端通訊的時候，對於這個網路通訊的機制應該如何設計，才能保證效能最優呢？甚至通過優秀的設計，讓效能提升10倍以上。

我們本文就以Kafka為例來給大家分析一下，Kafka在客戶端與服務端通訊的時候，底層的一些網路通訊相關的機制如何設計以及如何進行優化的。

1、客戶端與服務端的互動

假如我們用kafka作為訊息中介軟體，勢必會有客戶端作為生產者向他傳送訊息，這個大家應該都可以理解。

對於Kafka來說，他本身是支援分散式的訊息儲存的，什麼意思呢？

比如說現在你有一個“Topic”，一個“Topic”你就可以理解為一個訊息資料的邏輯上的集合。

比如現在你要把所有的訂單資料都傳送到一個“Topic”裡去，那麼這個“Topic”就叫做“OrderTopic”，裡面都放的是訂單資料。

接著這個“Topic”的資料可能量很大很大，不可能放在一臺機器上吧？

所以呢，我們就可以分散儲存在多臺Kafka的機器上，每臺機器儲存一部分的資料即可。

這就是Kafka的分散式訊息儲存的機制，每個Kafka服務端叫做一個Broker，負責管理一臺機器上的資料。

一起來看看下面的圖：

一個“Topic”可以拆分為多個“Partition”，每個“Partition”儲存一部分資料，每個Partition都可以放在不同的Kafka Broker機器上，這樣就實現了資料分散儲存在多臺機器上的效果了。

然後客戶端在傳送訊息到Kafka Broker的時候，比如說你限定了“OrderTopic”的訂單資料拆分為3個“Partition”，那麼3個“Partition”分別放在一個Kafka Broker上，那麼也就是要把所有的訂單資料分發到三個Kafka Broker上去。

此時就會預設情況下走一個負載均衡的策略，舉個例子，假設訂單資料一共有3萬條，就會給每個Partition分發1萬條訂單訊息，這樣訂單資料均勻分散在了3臺Broker機器上。

整個過程，如下圖所示：

2、頻繁網路通訊帶來的效能低下問題

好了，現在問題來了，客戶端在傳送訊息給Kafka Broker的時候，比如說現在要傳送一個訂單到Kafka上去，此時他是怎麼傳送過去呢？

是直接一條訂單訊息就對應一個網路請求，傳送到一臺Broker上去嗎？

如果是這樣做的話，那勢必會導致頻繁的跟一臺broker進行網路通訊，頻繁的網路通訊，每次都涉及到複雜的網路連線、傳輸的流程，那麼進而會導致客戶端效能的低下。

給大家舉個例子，比如說每次通過一個網路通訊傳送一條訂單到broker，需要耗時10ms。

那麼如果一個訂單就一次網路通訊傳送到broker，每秒最多就是傳送100個訂單了，大家想想，是不是這個道理？

但是假如說你每秒有10000個訂單要傳送，此時就會造成你的傳送效能遠遠跟不上你的需求，也就是效能的低下，看起來你的系統傳送訂單到kafka的速度就是特別的慢。

3、batch機制：多條訊息打包成一個batch

所以首先針對這個問題，kafka做的第一個優化，就是實現了batch機制。

這個意思就是說，他會在客戶端放一個記憶體緩衝區，每次你寫一條訂單先放到記憶體緩衝區裡去，然後在記憶體緩衝區裡，會把多個訂單給打包起來成為一個batch。

比如說預設kafka規定的batch的大小是16kb，那麼意思就是，你預設就是多條訂單湊滿16kb的大小，就會成為一個batch，然後他就會把這個batch通過網路通訊傳送到broker上去。

假如說一個batch傳送到broker，同樣也是耗費10ms而已，但是一個batch裡可以放入100條訂單，那麼1秒是不是可以傳送100個batch？

此時，1秒是不是就可以傳送10000條訂單出去了？

而且在打包訊息形成batch的時候，是有講究的，你必須是傳送到同一個Topic的同一個Partition的訊息，才會進入一個batch。

這個batch裡就代表要傳送到同一個Partition的多條訊息，這樣後續才能通過一個網路請求，就把這個batch傳送到broker，對應寫入一個Parititon中。

4、request機制：多個batch打包成一個request

事情到這裡就結束了嗎？還沒有！

比如現在我們要是手頭有兩個Topic，每個Topic都有3個Partition，那麼每個Broker是不是就會存放2個Partition？其中1個Partition是Topic01的，1個Partition是Topic02的。

現在假如說針對Topic01的Partition02形成了一個batch，針對Topic02的Partition02也形成了一個batch，但是這兩個batch其實都是發往同一個Broker的，如上圖的第二個Broker。

此時，還是一個網路請求傳送一個batch過去嗎？

其實就完全沒必要了，完全此時可以把多個發往同一個Broker的batch打包成一個request，然後一個request通過一次網路通訊傳送到 那個Broker上去。

假設一次網路通訊還是10ms，那麼這一次網路通訊就傳送了2個batch過去。

通過這種多個batch打包成一個request一次性發往Broker的方式，又進一步提升了網路通訊的效率和效能。

其實 batch機制 + request 機制，都是想辦法把很多資料打包起來，然後一次網路通訊儘量多傳送一些資料出去，這樣可以提升單位時間內傳送資料的數量。

這個單位時間內傳送資料的數量，也就是所謂的“吞吐量”，也就是單位時間內可以傳送多少資料到broker上去。

比如說每秒鐘可以傳送3萬條訊息過去，這就是代表了客戶端的“吞吐量”有多大。

因此，通過搞清楚這個原理，就可以學習到這種非常優秀的設計思想。而且在面試的時候，如果跟面試官聊到kafka，也可以跟面試官侃侃kafka底層，是如何有效的提升網路通訊效能的。

最後再來一張圖，作為全文總結。