[[336169]]

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

我們經(jīng)常會面臨這樣的問題，在確定某個topic下應該設置多少分區(qū)數(shù)，有時并不知道應該如何設置，如何評估等?；蛘邉e人問你當前kafka集群中，具體的業(yè)務topic中分區(qū)數(shù)是多少，是如何知道需要多少分區(qū)或怎么選擇比較適合的分區(qū)數(shù)。

1.結合業(yè)務場景和非業(yè)務條件

那么我們應該如何選擇合適的分區(qū)數(shù)呢?

具體的業(yè)務具體分析。

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

2.使用壓測工具，得出最佳分區(qū)數(shù)

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

生產(chǎn)者性能測試腳本：kafka-producer-perf-test.sh

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

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

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

3.吞吐量越高并不會一直與分區(qū)數(shù)有關

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

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

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

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

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

4.分區(qū)數(shù)與操作系統(tǒng)有關

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

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

5.注意消息寫入分區(qū)策略

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

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

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

如果與Key關聯(lián)較弱的應用，我們可以在未來根據(jù)實際情況進行增加分區(qū)數(shù)。

6.分區(qū)數(shù)會影響系統(tǒng)可用性

Kafka通過多副本機制實現(xiàn)集群高可用和高可靠，每個分區(qū)至少會有一個或多個副本，每個副本會存在于不同的Broker節(jié)點，并且只有l(wèi)eader副本對外提供服務。

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

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

7.分區(qū)數(shù)越多也會增加耗時

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

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

8.分區(qū)數(shù)理論參考設置值

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

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

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

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

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

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

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