Kafka分割槽介紹
阿新 • • 發佈：2019-02-10
原文地址：http://www.cnblogs.com/dt-zhw/p/5631060.html
Kafka中分割槽深度解析
今天主要談Kafka中的分割槽數和consumer中的並行度。從使用Kafka的角度說，這些都是至關重要的。
分割槽原則
Partition代表一個topic的分割槽，可以看到在構造時註冊了zookeeper，也就是說kafka在分割槽時，是被zk管理的。
在實際儲存資料時，怎麼確定分割槽。
咱們從kafka的設計開始，為了完成高吞吐性，關鍵有兩點設計：
- 使用了磁碟作業系統級的頁page的訪問，據說在順序讀寫時比使用記憶體速度更快。
- 使用Topic進行分佈化，可以突破一臺機器的限制。consumer和producer都是基於Topic的多執行緒操作，其中每個執行緒都會操作一個分割槽。
也就是分割槽是高吞吐的一個關鍵。從具體實現看，每次來請求的時候，都會用一條新的執行緒來處理，每次consumer或者producer，背後都有一個socketServer，提供NIO操作。
那是不是說Kafka只要topic越多，上面的partition越多，吞吐就越大麼？凡事都有利弊，這裡有幾點考慮。
- 當分割槽變多時，伺服器需要開闢更多的執行緒，有更多的記憶體消耗和CPU的使用，太多的時候，會產生太多的控制代碼，那麼管理方面消耗就會過大。
- kafka本身在執行時，每個producer在寫資料時，都有一個cache，達到量之後，會把具體的訊息傳送給kafka叢集，分割槽越多的情況下，從producer角度，cache就越大，記憶體消耗越多。
- kafka cluster有很多的元件，在分割槽數較多時會進行大量的管理，會產生大量的控制代碼。
- ReplicaManager 都要管理每個parition，需要儲存相關的控制代碼，並進行leader、follower與zk互動，在選舉過程中會有短暫的不可用，當分割槽過多時，讓zk選舉的工作也會特別龐大。
所以，從工作角度，是需要設定一個合適的分割槽數，這個是需要根據實際資料情況進行訓練的。
分割槽過程
下面讓我們具體跟蹤一下分割槽的過程。
Producer
首先從傳送資料開始：
資料本身一般有key，則直接獲取指定，否則是使用partitioner進行隨機選取。
隨機計算時會根據Hash值進行計算。
Consumer
預設會用一條執行緒來消費資料，預設是一個分割槽一個執行緒，一個執行緒可以消費很多分割槽的資料。
在實現時，會有一個queue阻塞佇列，如果沒有訊息的話，會阻塞的一直等訊息過來。讀取資料時會有一個策略，決定了每個consumer中的執行緒讀取哪些分割槽。