Kafka如何選擇合適的分區(qū)數(shù)

本篇文章給大家分享的是有關(guān)Kafka如何選擇合適的分區(qū)數(shù)，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

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

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

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

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

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

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

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

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

消費(fèi)者性能測試腳本：kafka-consumer-perf-test.sh

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

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

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

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

但是，事實(shí)真的是這樣嗎?

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

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

同樣，消息消費(fèi)的吞吐量與業(yè)務(wù)邏輯消費(fèi)速度等有關(guān)。

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

分區(qū)數(shù)也不能無限制的增加，因?yàn)槠湔加昧宋募枋龇?，進(jìn)程可支配的文件描述符是有限的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.實(shí)際情況具體分析，切勿盲目

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

因?yàn)橄到y(tǒng)的主要瓶頸在于es的寫入能力，造成消費(fèi)速度慢，從而引起海量日志消息的堆積。所以分析出當(dāng)前的主要問題(瓶頸等)很重要，切記不能隨意或盲目設(shè)置分區(qū)數(shù)。

以上就是Kafka如何選擇合適的分區(qū)數(shù)，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。