您好,登錄后才能下訂單哦!
如何為Kafka集群確定合適的分區(qū)數(shù)以及分區(qū)數(shù)過多帶來的弊端,針對這個問題,這篇文章詳細介紹了相對應(yīng)的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
Kafka高吞吐量的原因之一就是通過partition將topic中的消息保存到Kafka集群中不同的broker中。無論是Kafka的producer,還是consumer都可以并發(fā)操作topic中的partition,因此partition是Kafka并行度調(diào)優(yōu)的最小單元。
理論上說,如果一個topic分區(qū)越多,理論上整個集群所能達到的吞吐量就越大。
但是,實際生產(chǎn)中Kafka topic的分區(qū)數(shù)真的配置越多越好嗎?很顯然不是!
分區(qū)數(shù)過多會有以下弊端:
Kafka0.8.2之后,在客戶端producer有個參數(shù)batch.size,默認是16KB。它會為每個分區(qū)緩存消息,在數(shù)據(jù)積累到一定大小或者足夠的時間時,積累的消息將會從緩存中移除并發(fā)往broker節(jié)點。這個功能是為了提高性能而設(shè)計,但是隨著分區(qū)數(shù)增多,這部分緩存所需的內(nèi)存占用也會更多。
與此同時,consumer端在消費消息時的內(nèi)存占用、以及為達到更高的吞吐性能開啟的consumer線程數(shù)也會隨著分區(qū)數(shù)增加而增加。比如有10000個分區(qū),同時consumer線程數(shù)要匹配分區(qū)數(shù)(大部分情況下是最佳的消費吞吐量配置)的話,那么在consumer client就要創(chuàng)建10000個線程,那么在consumer client就要創(chuàng)建10000個線程,也需要創(chuàng)建大約10000個Socket去獲取分區(qū)數(shù)據(jù)。線程的開銷成本很顯然是不容小覷的!
Kafka端對端延遲定義為producer端發(fā)布消息到consumer端接收消息所需要的時間,即consumer接收消息的時間減去producer發(fā)布消息的時間。
Kafka只有在消息提交之后,才會將消息暴露給消費者。例如,消息在所有in-sync副本列表同步復(fù)制完成之后才暴露。因此,in-sync副本復(fù)制所花時間將是kafka端對端延遲的最主要部分。在默認情況下,每個broker從其他broker節(jié)點進行數(shù)據(jù)副本復(fù)制時,該broker節(jié)點只會為此工作分配一個線程,該線程需要完成該broker所有partition數(shù)據(jù)的復(fù)制。
注意,上述問題可以通過增大kafka集群來進行緩解。例如,將1000個分區(qū)leader放到一個broker節(jié)點和放到10個broker節(jié)點,他們之間的延遲是存在差異的。在10個broker節(jié)點的集群中,每個broker節(jié)點平均需要處理100個分區(qū)的數(shù)據(jù)復(fù)制。此時,端對端的延遲將會從原來的數(shù)十毫秒變?yōu)閮H僅需要幾毫秒。
Kafka通過多副本復(fù)制技術(shù),實現(xiàn)Kafka集群的高可用和穩(wěn)定性。每個partition都會有多個數(shù)據(jù)副本,每個副本分別存在于不同的broker。所有的數(shù)據(jù)副本中,有一個數(shù)據(jù)副本為leader,其他的數(shù)據(jù)副本為follower。
在Kafka集群內(nèi)部,所有的數(shù)據(jù)副本皆采用自動化的方式進行管理,并且確保所有的數(shù)據(jù)副本的數(shù)據(jù)皆保持同步狀態(tài)。不論是producer端還是consumer端發(fā)往partition的請求,都通過leader數(shù)據(jù)副本所在的broker進行處理。當(dāng)broker發(fā)生故障時,對于leader數(shù)據(jù)副本在該broker的所有partition將會變得暫時不可用。Kafka將會自動在其它數(shù)據(jù)副本中選擇出一個leader,用于接收客戶端的請求。這個過程由Kafka controller節(jié)點broker自動完成,主要是從Zookeeper讀取和修改受影響partition的一些元數(shù)據(jù)信息。
在通常情況下,當(dāng)一個broker有計劃地停止服務(wù)時,那么controller會在服務(wù)停止之前,將該broker上的所有l(wèi)eader一個個地移走。由于單個leader的移動時間大約只需要花費幾毫秒,因此從客戶層面看,有計劃的服務(wù)停機只會導(dǎo)致系統(tǒng)在很小時間窗口中不可用。(注:在有計劃地停機時,系統(tǒng)每一個時間窗口只會轉(zhuǎn)移一個leader,其他leader皆處于可用狀態(tài)。)
然而,當(dāng)broker非計劃地停止服務(wù)時(例如,kill -9方式),系統(tǒng)的不可用時間窗口將會與受影響的partition數(shù)量有關(guān)。假如,一個2節(jié)點的kafka集群中存在2000個partition,每個partition擁有2個數(shù)據(jù)副本。當(dāng)其中一個broker非計劃地宕機,所有1000個partition同時變得不可用。假設(shè)每一個partition恢復(fù)時間是5ms,那么1000個partition的恢復(fù)時間將會花費5秒鐘。因此,在這種情況下,用戶將會觀察到系統(tǒng)存在5秒鐘的不可用時間窗口。
總而言之,通常情況下Kafka集群中越多的partition會帶來越高的吞吐量。但是,如果Kafka集群中partition總量過大或者單個broker節(jié)點partition過多,都可能會對系統(tǒng)的可用性和消息延遲帶來潛在的負面影響,需要引起我們的重視。
在partition級別上達到均衡負載是實現(xiàn)吞吐量的關(guān)鍵,合適的partition數(shù)量可以達到高度并行讀寫和負載均衡的目的,需要根據(jù)每個分區(qū)的生產(chǎn)者和消費者的目標(biāo)吞吐量進行估計。
可以遵循一定的步驟來確定分區(qū)數(shù):根據(jù)某個topic日常"接收"的數(shù)據(jù)量等經(jīng)驗確定分區(qū)的初始值,然后測試這個topic的producer吞吐量和consumer吞吐量。假設(shè)它們的值分別是Tp和Tc,單位可以是MB/s。然后假設(shè)總的目標(biāo)吞吐量是Tt,那么numPartitions = Tt / max(Tp, Tc)
關(guān)于如何為Kafka集群確定合適的分區(qū)數(shù)以及分區(qū)數(shù)過多帶來的弊端問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。