[[336169]]

本文轉載自微信公眾號「搬運工來架構」，作者cocodroid 。轉載本文請聯系搬運工來架構公眾號。

我們經常會面臨這樣的問題，在確定某個topic下應該設置多少分區數，有時并不知道應該如何設置，如何評估等。或者別人問你當前kafka集群中，具體的業務topic中分區數是多少，是如何知道需要多少分區或怎么選擇比較適合的分區數。

1.結合業務場景和非業務條件

那么我們應該如何選擇合適的分區數呢?

具體的業務具體分析。

但是前期我們可以根據這些條件：實際業務場景(消息總量，消息生產或消費頻率，要求的吞吐量等)、軟件條件、硬件條件、負載情況等，進行大致的評估我們可以設置topic多少分區數。

2.使用壓測工具，得出最佳分區數

kafka官方也提供了腳本方便我們針對我們的kafka集群做測試，我們可以測試當前提供的硬件條件進行壓測，得出當前機器環境到底能支持多少分區數，從而達到盡量最優的方案。

生產者性能測試腳本：kafka-producer-perf-test.sh

消費者性能測試腳本：kafka-consumer-perf-test.sh

設置好topic的某個分區數，之后我們可以選擇不同的參數：比如消息發送總量、單條消息大小、吞吐量、acks、消費線程數等等，這樣壓測之后就能得出一份測試報告，報告包含的數據有：50%/90%/95%/99%的消息處理耗時、平均處理耗時、每秒消息發送吞吐量、每秒拉取的消息的字節大小/消息數量、消費總數、再平衡時間、按消息計數/消息大小計算的吞吐量等等。

合適的增加分區數是可以提高吞吐量，但超過一定的閾值之后，吞吐量也會隨之下降。如果生產上對吞吐量有一定的要求，可以在生產機器硬件條件下進行壓測，得出適合你的最優分區數。

3.吞吐量越高并不會一直與分區數有關

對kafka生產者而言，數據寫入每個分區是可以并行進行的。對kafka消費者而言，每個分區只能給一個消費者線程消費，所以消費組的消費并行度依賴于分區數。這樣看來好像分區數越多，理論上吞吐量應該越高。

但是，事實真的是這樣嗎?

消息中間件kafka的吞吐量并不只是跟分區有關。

消息寫入(生產)的吞吐量與這些有關：消息大小、消息壓縮方式、消息發送方式(同步或異步)、消息確認類型acks、副本因子等。

同樣，消息消費的吞吐量與業務邏輯消費速度等有關。

4.分區數與操作系統有關

分區數也不能無限制的增加，因為其占用了文件描述符，進程可支配的文件描述符是有限的。

一般如果要設置比較大的分區數，要特別留意是否超過系統的最的大描述符文件。雖然可以通過改系統配置，但是應盡量避免這種，畢竟文件句柄也是有開銷的。

5.注意消息寫入分區策略

我們知道消費寫入哪個分區，默認或者有些會根據Key計算其應寫入哪個分區，這個時候就要考慮與Key較強關聯的應用是否會影響你的使用場景。

比如有些應用場景可能只是要求某個分區內消息有序，如果一旦調整分區數，就有可能影響這種使用場景。

所以我們一般會盡量配置較好的分區數，盡量滿足未來2年內目標的吞吐量。

如果與Key關聯較弱的應用，我們可以在未來根據實際情況進行增加分區數。

6.分區數會影響系統可用性

Kafka通過多副本機制實現集群高可用和高可靠，每個分區至少會有一個或多個副本，每個副本會存在于不同的Broker節點，并且只有leader副本對外提供服務。

kafka集群內部所有副本都采用了自動化的方式進行管理，所有副本的數據都能保持一定程度上的同步。當Broker發生故障，leader副本所在的Broker節點上的所有分區將處于暫不可用狀態。

此時集群內follower副本就會重新進行選舉出leader副本，整個過程由kafka控制器負責，并且集群上的分區會存在暫時不可用，并且如果分區數過多，這個不可用的時間窗口就會更大。

7.分區數越多也會增加耗時

分區數越多，kafka在正常啟動和關閉的耗時也會變得越長。

與此同時，主題分區數也會在日志清理時增加耗時，也會在刪除時耗費更多的時間。在舊版本上是比較明顯，在新版本已經得到了改善。

8.分區數理論參考設置值

一般情況下，分區數可以配置為Broker節點數的整數倍，比如：Broker節點是3，那么可以設置分區數為3、6、9。

但是在broker節點數龐大的情況下，比如大幾十、上百、上千則不合適，一般這種也是比較極少的吧，除非有BAT的量級。如果需要可以在選定分區數時可以進一步考慮引入機架等參考因素。

9.實際情況具體分析，切勿盲目

最后，當你后期增加分區數時，要注意是否有必要或合理。筆者曾見過這種場景：將日志消費后寫入es，但是存在消息堆積嚴重，于是將分區數從6個增加到12個，此時對堆積情況并沒有很好得到改善，甚至出現更差(比如同一日志文件日志數據出現不連續，即有序)，最后只能刪掉主題，重新設置原來的分區數。

因為系統的主要瓶頸在于es的寫入能力，造成消費速度慢，從而引起海量日志消息的堆積。

所以分析出當前的主要問題(瓶頸等)很重要，切記不能隨意或盲目設置分區數。

參考書籍：《深入理解kafka》