分區多的優點

kafka使用分區將topic的消息打散到多個分區分布保存在不同的broker上，實現了producer和consumer消息處理的高吞吐量。Kafka的producer和consumer都可以多線程地并行操作，而每個線程處理的是一個分區的數據。因此分區實際上是調優Kafka并行度的最小單元。對于producer而言，它實際上是用多個線程并發地向不同分區所在的broker發起Socket連接同時給這些分區發送消息；而consumer，同一個消費組內的所有consumer線程都被指定topic的某一個分區進行消費。

所以說，如果一個topic分區越多，理論上整個集群所能達到的吞吐量就越大。

分區不是越多越好

分區是否越多越好呢？顯然也不是，因為每個分區都有自己的開銷：

一、客戶端/服務器端需要使用的內存就越多

Kafka0.8.2之后，在客戶端producer有個參數batch.size，默認是16KB。它會為每個分區緩存消息，一旦滿了就打包將消息批量發出。看上去這是個能夠提升性能的設計。不過很顯然，因為這個參數是分區級別的，如果分區數越多，這部分緩存所需的內存占用也會更多。假設你有10000個分區，按照默認設置，這部分緩存需要占用約157MB的內存。而consumer端呢？我們拋開獲取數據所需的內存不說，只說線程的開銷。如果還是假設有10000個分區，同時consumer線程數要匹配分區數(大部分情況下是最佳的消費吞吐量配置)的話，那么在consumer client就要創建10000個線程，也需要創建大約10000個Socket去獲取分區數據。這里面的線程切換的開銷本身已經不容小覷了。

服務器端的開銷也不小，如果閱讀Kafka源碼的話可以發現，服務器端的很多組件都在內存中維護了分區級別的緩存，比如controller，FetcherManager等，因此分區數越多，這種緩存的成本就越大。

二、文件句柄的開銷

每個分區在底層文件系統都有屬于自己的一個目錄。該目錄下通常會有兩個文件：base_offset.log和base_offset.index。Kafak的controller和ReplicaManager會為每個broker都保存這兩個文件句柄(file handler)。很明顯，如果分區數越多，所需要保持打開狀態的文件句柄數也就越多，最終可能會突破你的ulimit -n的限制。

三、降低高可用性

Kafka通過副本(replica)機制來保證高可用。具體做法就是為每個分區保存若干個副本(replica_factor指定副本數)。每個副本保存在不同的broker上。其中的一個副本充當leader 副本，負責處理producer和consumer請求。其他副本充當follower角色，由Kafka controller負責保證與leader的同步。如果leader所在的broker掛掉了，contorller會檢測到然后在zookeeper的幫助下重選出新的leader——這中間會有短暫的不可用時間窗口，雖然大部分情況下可能只是幾毫秒級別。但如果你有10000個分區，10個broker，也就是說平均每個broker上有1000個分區。此時這個broker掛掉了，那么zookeeper和controller需要立即對這1000個分區進行leader選舉。比起很少的分區leader選舉而言，這必然要花更長的時間，并且通常不是線性累加的。如果這個broker還同時是controller情況就更糟了。

如何確定分區數量呢？　　

可以遵循一定的步驟來嘗試確定分區數：創建一個只有1個分區的topic，然后測試這個topic的producer吞吐量和consumer吞吐量。假設它們的值分別是Tp和Tc，單位可以是MB/s。然后假設總的目標吞吐量是Tt，那么分區數 =  Tt / max(Tp, Tc)

說明：Tp表示producer的吞吐量。測試producer通常是很容易的，因為它的邏輯非常簡單，就是直接發送消息到Kafka就好了。Tc表示consumer的吞吐量。測試Tc通常與應用的關系更大， 因為Tc的值取決于你拿到消息之后執行什么操作，因此Tc的測試通常也要麻煩一些。

一條消息如何知道要被發送到哪個分區？

按照key值分配

默認情況下，Kafka根據傳遞消息的key來進行分區的分配，即hash(key) % numPartitions：

def partition(key: Any, numPartitions: Int): Int = {    Utils.abs(key.hashCode) % numPartitions }

這保證了相同key的消息一定會被路由到相同的分區。key為null時，從緩存中取分區id或者隨機取一個。如果你沒有指定key，那么Kafka是如何確定這條消息去往哪個分區的呢？

不指定key時，Kafka幾乎就是隨機找一個分區發送無key的消息，然后把這個分區號加入到緩存中以備后面直接使用——當然了，Kafka本身也會清空該緩存（默認每10分鐘或每次請求topic元數據時）。

Consumer個數與分區數有什么關系？

topic下的一個分區只能被同一個consumer group下的一個consumer線程來消費，但反之并不成立，即一個consumer線程可以消費多個分區的數據，比如Kafka提供的ConsoleConsumer，默認就只是一個線程來消費所有分區的數據。