在之前的例子裡( Kafka生産者——向 Kafka寫入資料 )， ProducerRecord 對象包含了目标主題、鍵和值。 Kafka 的消息是 一個個 鍵值對， ProducerRecord對象可以隻包含目标主題和值，鍵可以設定為預設的 null，不過大多數應用程式會用到鍵。鍵有兩個用途 :可以作為消息的附加資訊，也可以用來決定消息該被寫到主題的哪個分區。擁有相同鍵的悄息将被寫到同一個分區。 也就是說，如果一個程序隻從一個主題的分區讀取資料(第 4章會介紹更多細節)，那麼具有相 同鍵的所有記錄都會被該程序讀取。要建立一個包含鍵值的記錄，隻需像下面這樣建立 ProducerRecord 對象:
如果鍵值為 null， 井且使用了預設的分區器，那麼記錄将被随機地發送到主題内各個可用的分區上。分區器使用輪詢(Round Robin)算法将消息均衡地分布到各個分區上。
如果鍵不為空，并且使用了預設的分區器，那麼Kafka會對鍵進行散列(使用 Kafka 自己的雜湊演算法，即使更新Java版本，散列值也不會發生變化)，然後根據散列值把消息映射到特定的分區上。這裡的關鍵之處在于 ，同一個鍵總是被映射到同一個分區上 ，是以在進 行映射時，我們會使用主題所有的分區，而不僅僅是可用的分區 。這也意味着，如果寫入資料的分區是不可用的，那麼就會發生錯誤。但這種情況很少發生。我們将在第 6章讨論 Kafka 的複制功能和可用性。
隻有在不改變主題分區數量的情況下，鍵與分區之間的映射才能保持不變 。舉個例子，在分區數量保持不變的情況下，可以保證使用者 045189 的記錄總是被寫到分區 34。在從分區讀取資料肘，可以進行各種優化。不過，一旦主題增加了新的分區，這些就無法保證 了——舊資料仍然留在分區 34，但新的記錄可能被寫到其他分區上 。 如果要使用鍵來映射分區，那麼最好在建立主題的時候就把分區規劃好，而且永遠不要增加新分區。
實作自定義分區政策
我們已經讨論了預設分區器的特點，它是使用次數最多的分區器。不過 ，除了散列分區之 外，有時候也需要對資料進行不一樣的分區。假設你是一個 B2B 供應商，你有 一 個大客 戶，它是手持裝置 Banana 的制造商。 Banana 占據了你整體業務 10% 的份額。如果使用默 認的散列分區算怯， Banana 的賬号記錄将和其他賬号記錄一起被配置設定給相同的分區，導緻 這個分區比其他分區要大一些。伺服器可能是以出現存儲空 間不足、處理緩慢等問題。我 們需要給 Banana 配置設定單獨的分區，然後使用散列分區算住處理其他賬号 。
下面是一個自定義分區器的例子 :
