如何決定kafka集羣中話題的分區的數量

http://blog.csdn.net/greenappple/article/details/50933872

 

如何決定kafka集羣中topic,partition的數量，這是許多kafka用戶常常遇到的問題。本文列舉闡述幾個重要的決定因素，以提供一些參考。

分區多吞吐量更高

    一個話題topic的各個分區partiton之間是並行的。在producer和broker方面，寫不一樣的分區是徹底並行的。所以一些昂貴的操做好比壓縮，能夠得到更多的資源，由於有多個進程。在consumer方面，一個分區的數據能夠由一個consumer線程在拉去數據。分區多，並行的consumer（同一個消費組）也能夠多。所以一般，分區越多吞吐量越高。

    基於吞吐量能夠得到一個粗略的計算公式。先測量獲得在只有一個分區的狀況下，Producer的吞吐量(P)和Consumer的吞吐量(C)。那若是總的目標吞吐量是T的話，max(T/P,T/C)就是須要的最小分區數。在單分區的狀況下，Producer的吞吐量能夠經過一些配置參數，好比bath的大小、副本的數量、壓縮格式、ack類型來測得。而Consumer的吞吐量一般取決於應用程序處理每一天消息邏輯。這些都是須要切合實際測量。

    隨着時間推移數據量的增加可能會須要增長分區。有一點須要注意的是，Producer者發佈消息經過key取哈希後映射分發到一個指定的分區，當分區數發生變化後，會帶來key和分區映射關係發生變化。可能某些應用程序依賴key和分區映射關係，映射關係變化了，程序就須要作相應的調整。爲了不這種key和分區關係帶來的應用程序修改。因此在分區的時候儘可能提早考慮，將來一年或兩年的對分區數據量的要求。

   除了吞吐量，還有一些其餘的因素，在定分區的數目時是值得考慮的。在某些狀況下，太多的分區也可能會產生負面影響。

 

分區多須要的打開的文件句柄也多

    每一個分區都映射到broker上的一個目錄，每一個log片斷都會有兩個文件（一個是索引文件，另外一個是實際的數據文件）。分區越多所須要的文件句柄也就越多，能夠經過配置操做系統的參數增長打開文件句柄數。

 

分區多增長了不可用風險

    kafka支持主備複製，具有更高的可用性和持久性。一個分區（partition）能夠有多個副本，這些副本保存在不一樣的broker上。每一個分區的副本中都會有一個做爲Leader。當一個broker失敗時，Leader在這臺broker上的分區都會變得不可用，kafka會自動移除Leader，再其餘副本中選一個做爲新的Leader。Producer和Consumer都只會與Leader相連。

    通常狀況下，當一個broker被正常關機時，controller主動地將Leader從正在關機的broker上移除。移動一個Leader只須要幾毫秒。然當broker出現異常致使關機時，不可用會與分區數成正比。假設一個boker上有2000個分區，每一個分區有2個副本，那這樣一個boker大約有1000個Leader，當boker異常宕機，會同時有1000個分區變得不可用。假設恢復一個分區須要5ms，1000個分區就要5s。

    分區越多，在broker異常宕機的狀況，恢復所需時間會越長，不可用風險會增長。

 

分區多會增長點到點的延遲

    這個延遲須要體如今兩個boker間主備數據同步。在默認狀況下，兩個boker只有一個線程負責數據的複製。

    根據經驗，每一個boker上的分區限制在100*b*r內（b指集羣內boker的數量，r指副本數量）。

 

分區多會增長客戶端的內存消耗

    kafka0.8.2後有個比較好的特點，新的Producer能夠容許用戶設置一個緩衝區，緩存必定量的數據。當緩衝區數據到達設定量或者到時間，數據會從緩存區刪除發往broker。若是分區不少，每一個分區都緩存必定量的數據量在緩衝區，極可能會佔用大量的內存，甚至超過系統內存。

    Consumer也存在一樣的問題，會從每一個分區拉一批數據回來，分區越多，所需內存也就越大。

    根據經驗，應該給每一個分區分配至少幾十KB的內存。

 

總結

     在一般狀況下，增長分區能夠提供kafka集羣的吞吐量。然而，也應該意識到集羣的總分區數或是單臺服務器上的分區數過多，會增長不可用及延遲的風險。

 

     http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/