前言
經過上篇文章的簡單實戰之後，今天來聊聊生產者將消息從客戶端發送到 Broker 上背後發生了哪些故事，看不看由你，但是我保證可以本篇文章你一定可以學到應用背後的一些實質東西。
本文我們從以下 4 個方面來探討下一條消息如何被準確的發送到 Broker 的 partition 上。
1. 客戶端組件
2. 客戶端緩存存儲模型
3. 確定消息的 partition 位置
4. 發送線程的工作原理
客戶端組件
KafkaProducer:
KafkaProducer 是一個生產者客戶端的進程，通過該對象啓動生產者來發送消息。
RecordAccumulator:
RecordAccumulator 是一個記錄收集器，用於收集客戶端發送的消息，並將收集到的消息暫存到客戶端緩存中。
Sender:
Sender 是一個發送線程，負責讀取記錄收集器中緩存的批量消息，經過一些中間轉換操作，將要發送的數據準備好，然後交由 Selector 進行網絡傳輸。
Selector:
Selector 是一個選擇器，用於處理網絡連接和讀寫處理，使用網絡連接處理客戶端上的網絡請求。
通過使用以上四大組件即可完成客戶端消息的發送工作。消息在網絡中傳輸的方式只能通過二級制的方式，所以首先需要將消息序列化爲二進制形式緩存在客戶端，kafka 使用了雙端隊列的方式將消息緩存起來，然後使用發送線程（Sender）讀取隊列中的消息交給 Selector 進行網絡傳輸發送給服務端（Broker）
以上爲發送消息的主流程，附上部分源碼供大家參考，接下來分析下幾個非常重要流程的具體實現原理。
客戶端緩存存儲模型
從上圖可以看出，一條消息首先需要確定要被存儲到那個 partition 對應的雙端隊列上；其次，存儲消息的雙端隊列是以批的維度存儲的，即 N 條消息組成一批，一批消息最多存儲 N 條，超過後則新建一個組來存儲新消息；其次，新來的消息總是從左側寫入，即越靠左側的消息產生的時間越晚；最後，只有當一批消息湊夠 N 條後纔會發送給 Broker，否則不會發送到 Broker 上。
瞭解了客戶端存儲模型後，來探討下確定消息的 partition（分區）位置？
確定消息的 partition 位置
消息可分爲兩種，一種是指定了 key 的消息，一種是沒有指定 key 的消息。
對於指定了 key 的消息，partition 位置的計算方式爲：Utils.murmur2(key) % numPartitions，即先對 key 進行哈希計算，然後在於 partition 個數求餘，從而得到該條消息應該被存儲在哪個 partition 上。
對於沒有指定 key 的消息，partition 位置的計算方式爲：採用 round-robin 方式確定 partition 位置，即採用輪詢的方式，平均的將消息分佈到不同的 partition 上，從而避免某些 partition 數據量過大影響 Broker 和消費端性能。
注意
由於 partition 有主副的區分，此處參與計算的 partition 數量是當前有主 partition 的數量，即如果某個 partition 無主的時候，則此 partition 是不能夠進行數據寫入的。
稍微解釋一下，主副 partition 的機制是爲了提高 kafka 系統的容錯性的，即當某個 Broker 意外宕機時，在此 Broker 上的主 partition 狀態爲不可讀寫時（只有主 partition 可對外提供讀寫服務，副 partition 只有數據備份的功能），kafka 會從主 partition 對應的 N 個副 partition 中挑選一個，並將其狀態改爲主 partition，從而繼續對外提供讀寫操作。
消息被確定分配到某個 partition 對應記錄收集器（即雙端隊列）後，接下來，發送線程（Sender）從記錄收集器中收集滿足條件的批數據發送給 Broker，那麼發送線程是如何收集滿足條件的批數據的？批數據是按照 partition 維度發送的還是按照 Broker 維度發送數據的？
發送線程的工作原理
Sender 線程的主要工作是收集滿足條件的批數據，何爲滿足條件的批數據？緩存數據是以批維度存儲的，當一批數據量達到指定的 N 條時，就滿足發送給 Broker 的條件了。
partition 維度和 Broker 維度發送消息模型對比。
從圖中可以看出，左側按照 partition 維度發送消息，每個 partition 都需要和 Broker 建連，總共發生了四次網絡連接。而右側將分佈在同一個 Broker 的 partition 按組聚合後在與 Broker 建連，只需要兩次網絡連接即可。所以 Kafka 選擇右側的方式。
Sender 的主要工作
第一步：掃描記錄收集器中滿足條件的批數據，然後將 partition -> 批數據映射轉換成 BrokerId -> N 批數據的映射。第二步：Sender 線程會爲每個 BrokerId 創建一個客戶端請求，然後將請求交給 NetWorkClient，由 NetWrokClient 去真正發送網絡請求到 Broker。
NetWorkClient 的工作內容
Sender 線程準備好要發送的數據後，交由 NetWorkClient 來進行網絡相關操作。主要包括客戶端與服務端的建連、發送客戶端請求、接受服務端響應。完成如上一系列的工作主要由如下方法完成。
reday()方法。從記錄收集器獲取準備完畢的節點，並連接所有準備好的節點。
send()方法。爲每個節點創建一個客戶端請求，然後將請求暫時存到節點對應的 Channel（通道）中。
poll()方法。該方法會真正輪詢網絡請求，發送請求給服務端節點和接受服務端的響應。
總結
以上，即爲生產者客戶端的一條消息從生產到發送到 Broker 上的全過程。現在是不是就很清晰了呢？也許有些朋友會比較疑惑它的網絡請求模型是什麼樣的，作者就猜你會你會問，下一篇我們就來扒開它的神祕面紗看看其究竟是怎麼實現的，敬請期待。
原創不易，朋友們點個再看是對我最大的鼓勵，關注作者，系列文章不迷路。
