轉載：https://www.jianshu.com/p/cdfc3df9e4c6
kafka的每個topic都可以創建多個partition，partition的數量無上限，並不會像replica一樣受限於broker的數量，因此partition的數量可以隨心所欲的設置。那確定partition的數量就需要思考一些權衡因素。
越多的partition可以提供更高的吞吐量
在kafka中，單個partition是kafka並行操作的最小單元。每個partition可以獨立接收推送的消息以及被consumer消費，相當於topic的一個子通道，partition和topic的關系就像高速公路的車道和高速公路的關系一樣，起始點和終點相同，每個車道都可以獨立實現運輸，不同的是kafka中不存在車輛變道的說法，入口時選擇的車道需要從一而終。而kafka的吞吐量顯而易見，在資源足夠的情況下，partition越多速度越快。
這里提到的資源充足解釋一下，假設我現在一個partition的最大傳輸速度為p，目前kafka集群共有三個broker，每個broker的資源足夠支撐三個partition最大速度傳輸，那我的集群最大傳輸速度為3*3*p=9p，假設在不增加資源的情況下將partition增加到18個，每個partition只能以p/2的速度傳輸數據，因此傳輸速度上限還是9p，並不能再提升，因此吞吐量的設計需要考慮broker的資源上限。當然，kafka跟其他集群一樣，可以橫向擴展，再增加三個相同資源的broker，那傳輸速度即可達到18p。
越多的分區需要打開更多的文件句柄
在kafka的broker中，每個分區都會對照着文件系統的一個目錄。
在kafka的數據日志文件目錄中，每個日志數據段都會分配兩個文件，一個索引文件和一個數據文件。因此，隨着partition的增多，需要的文件句柄數急劇增加，必要時需要調整操作系統允許打開的文件句柄數。
更多的分區會導致端對端的延遲
kafka端對端的延遲為producer端發布消息到consumer端消費消息所需的時間，即consumer接收消息的時間減去produce發布消息的時間。kafka在消息正確接收后才會暴露給消費者，即在保證in-sync副本復制成功之后才會暴露，瓶頸則來自於此。在一個broker上的副本從其他broker的leader上復制數據的時候只會開啟一個線程，假設partition數量為n，每個副本同步的時間為1ms，那in-sync操作完成所需的時間即n*1ms，若n為10000，則需要10秒才能返回同步狀態，數據才能暴露給消費者，這就導致了較大的端對端的延遲。
越多的partition意味着需要更多的內存
在新版本的kafka中可以支持批量提交和批量消費，而設置了批量提交和批量消費后，每個partition都會需要一定的內存空間。假設為100k，當partition為100時，producer端和consumer端都需要10M的內存；當partition為100000時，producer端和consumer端則都需要10G內存。無限的partition數量很快就會占據大量的內存，造成性能瓶頸。
越多的partition會導致更長時間的恢復期
kafka通過多副本復制技術，實現kafka的高可用性和穩定性。每個partition都會有多個副本存在於多個broker中，其中一個副本為leader，其余的為follower。當kafka集群其中一個broker出現故障時，在這個broker上的leader會需要在其他broker上重新選擇一個副本啟動為leader，這個過程由kafka controller來完成，主要是從Zookeeper讀取和修改受影響partition的一些元數據信息。
通常情況下，當一個broker有計划的停機上，該broker上的partition leader會在broker停機前有次序的一一移走，假設移走一個需要1ms，10個partition leader則需要10ms，這影響很小，並且在移動其中一個leader的時候，其他九個leader是可用的，因此實際上每個partition leader的不可用時間為1ms。但是在宕機情況下，所有的10個partition
leader同時無法使用，需要依次移走，最長的leader則需要10ms的不可用時間窗口，平均不可用時間窗口為5.5ms，假設有10000個leader在此宕機的broker上，平均的不可用時間窗口則為5.5s。
更極端的情況是，當時的broker是kafka controller所在的節點，那需要等待新的kafka leader節點在投票中產生並啟用，之后新啟動的kafka leader還需要從zookeeper中讀取每一個partition的元數據信息用於初始化數據。在這之前partition leader的遷移一直處於等待狀態。
總結
通常情況下，越多的partition會帶來越高的吞吐量，但是同時也會給broker節點帶來相應的性能損耗和潛在風險，雖然這些影響很小，但不可忽略，因此需要根據自身broker節點的實際情況來設置partition的數量以及replica的數量。