【Kafka】《Kafka權威指南》——分區partition

在上篇的例子裏(【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 分配單獨的分區，而後使用散列分區算住處理其餘帳號 。

下面是一個自定義分區器的例子 :