當(dāng)前位置：首頁 > 科技 > 軟件

Kafka 如何基于 KRaft 實(shí)現(xiàn)集群最終一致性協(xié)調(diào)

來源：責(zé)編：時間：2024-06-05 17:44:34 133觀看

導(dǎo)讀一、架構(gòu)概覽 Zookeeper 提供了配置服務(wù)、分布式同步、命名服務(wù)、Leader 選舉和集群管理等功能，在大數(shù)據(jù)時代的開始很多開源產(chǎn)品都依賴 Zookeeper 來構(gòu)建，Apache Kafka 也不例外。但是隨著 Kafka 功能的演進(jìn)和應(yīng)用的

一、架構(gòu)概覽

Zookeeper 提供了配置服務(wù)、分布式同步、命名服務(wù)、Leader 選舉和集群管理等功能，在大數(shù)據(jù)時代的開始很多開源產(chǎn)品都依賴 Zookeeper 來構(gòu)建，Apache Kafka 也不例外。但是隨著 Kafka 功能的演進(jìn)和應(yīng)用的場景越來越多：

基于 Zookeeper 的協(xié)作模式，使得 Kafka 的集群一致性維護(hù)越來越復(fù)雜；
受到 Zookeeper 性能的限制，使得 Kafka 無法支撐更大的集群規(guī)模；
并且 Zookeeper 自身帶來的運(yùn)維復(fù)雜性和產(chǎn)品穩(wěn)定性，也同樣將復(fù)雜度和風(fēng)險(xiǎn)負(fù)擔(dān)傳遞到 Kafka 運(yùn)維人員；

因此作為 Zookeeper 的替代，Kafka 3.3.1 提供了 KRaft 元數(shù)據(jù)管理組件。

下圖來自于 KIP-500 [1]提案，左右分別是 Zookeeper 模式和 KRaft 模式的部署架構(gòu)圖。

圖片

在 Zookeeper （后面簡稱為 ZK）模式下：

運(yùn)維部署：3 個 ZK 節(jié)點(diǎn)；2..N 個 Broker 節(jié)點(diǎn)，其中一個 Broker 承擔(dān) Controller 的角色。除了拉起一套最小生產(chǎn)的 Kafka 集群需要至少 3 + N 的資源外，Kafka 的運(yùn)維人員要同時掌握 ZK 和 Kafka Broker 兩套完全不同的系統(tǒng)的運(yùn)維方式。
通信協(xié)調(diào)：ZK 節(jié)點(diǎn)之間通過 ZAB 協(xié)議進(jìn)行一致性協(xié)調(diào)；Broker 會通過 ZK 來選出一個 Controller 負(fù)責(zé)全局的協(xié)調(diào)，同時也會直接修改 ZK 里的數(shù)據(jù)；Controller 也會監(jiān)聽和修改 ZK 里的數(shù)據(jù)，并調(diào)用 Broker 來完成集群的協(xié)調(diào)。雖然 ZK 之間的一致性由 ZAB 來保障了，但是 ZK 與 Controller 之間和 Controller 與 Broker 之間的一致性是相對比較脆弱的。

在 KRaft 模式下：

運(yùn)維部署：3 個 Controller 節(jié)點(diǎn)；0..N 個 Broker 節(jié)點(diǎn)。Kafka 節(jié)點(diǎn)可以同時承擔(dān) Controller 和 Broker 兩個角色，因此一套最小生產(chǎn)集群只需要 3 個節(jié)點(diǎn)。在測試環(huán)境更可以只以 1 節(jié)點(diǎn)模式就可以輕量地拉起一個 Kafka 集群。
通信協(xié)調(diào)：Controller 節(jié)點(diǎn)底層通過 Raft 協(xié)議達(dá)成一致，Controller 的內(nèi)存狀態(tài)通過 #replay Raft Log 來構(gòu)建，因此 Controller 之間的內(nèi)存狀態(tài)都是一致的；Broker 訂閱 KRaft Log 維護(hù)和 Controller 一致的內(nèi)存狀態(tài)，并且通過事件驅(qū)動的方式執(zhí)行 Partition Reassignment 之類的操作來實(shí)現(xiàn)集群最終一致性協(xié)調(diào)。整個集群的狀態(tài)維護(hù)和一致性協(xié)調(diào)都是基于 KRaft 中的事件。

Raft 的原理和實(shí)現(xiàn)已經(jīng)有很多優(yōu)秀的文章介紹過了，就不在此贅述了。下面著重介紹一下 Kafka 如何基于 KRaft 實(shí)現(xiàn)集群的最終一致性協(xié)調(diào)。

二、最終一致性協(xié)調(diào)

最終一致性協(xié)調(diào)分為兩部分：Controller 內(nèi)存數(shù)據(jù)與 KRaft 的一致性；Broker （分區(qū) / 配置 / ...）狀態(tài)與期望的一致性。

2.1 Controller

Controller 在生產(chǎn)環(huán)境中通常由 3 個節(jié)點(diǎn)組成 Quorum，底層使用 KRaft 來進(jìn)行一致性協(xié)調(diào)，KRaft 的 Leader 即是 Controller Leader。

只有 Leader 會進(jìn)行請求處理，F(xiàn)ollower 只會跟隨 Replay KRaft 中的數(shù)據(jù)，請求處理流程簡要如下：

當(dāng) Leader 網(wǎng)絡(luò)層接收到 Broker 發(fā)來的請求后，會將請求首先放入到事件隊(duì)列中，由后臺的單線程來處理事件隊(duì)列中的請求。通過單線程處理機(jī)制簡化了并發(fā)編程的復(fù)雜度，并且確保所有請求可以順序處理；
單線程處理器運(yùn)行請求對應(yīng)的 Manager 邏輯。Manager 根據(jù)當(dāng)前內(nèi)存中維護(hù)的狀態(tài)，生成響應(yīng)和變更的 Records；
最后再把變更的 Records 提交到 KRaft 中，等多數(shù)派確認(rèn)后就可以將響應(yīng)返回，并 #replay(Records) 修改 Manager 維護(hù)的內(nèi)存狀態(tài)；
同時 Follower 也會將 KRaft 中的 Records #replay到內(nèi)存中，內(nèi)存數(shù)據(jù)持續(xù)的保持同步；

以 CAS(expectValue, newValue) 舉例說明上述的流程，假設(shè)內(nèi)存中的初始狀態(tài)為 1，Broker Client 提交了請求 CAS(1, 2) 到 Controller：

首先 Leader 會將請求放到事件隊(duì)列中；
然后 Manager 以單線程模式處理請求，判斷內(nèi)存中的值是 1，等于請求的 expectValue，因此生成成功響應(yīng)和 Record{value = 2};
最后再把變更的 Records 提交到 KRaft 中，KRaft 確認(rèn)后返回給請求方響應(yīng)，并將 Record{value = 2} replay 到 Manager，Manager 內(nèi)存狀態(tài)更新為 2；

簡而言之，Controller 簡版的處理時序如下：

開始處理請求 A -> Manager 生成響應(yīng)和 Records -> Records 在 KRaft 多數(shù)派確認(rèn) -> Manager#replay(Records) -> 返回響應(yīng) -> 處理下一條請求...

通過上述的處理時序，Controller 就可以做到“內(nèi)存狀態(tài)與 KRaft ”和“多節(jié)點(diǎn)之間的內(nèi)存狀態(tài)”的一致性：

內(nèi)存狀態(tài)與 KRaft ：Controller 的內(nèi)存狀態(tài)都是基于 KRaft 確認(rèn)的 Records 變更 #replay出來的，因此內(nèi)存狀態(tài)和 KRaft 保持一致；
多節(jié)點(diǎn)之間的內(nèi)存狀態(tài)：KRaft 底層保證了多節(jié)點(diǎn)的 KRaft Log 是一致的，然后基于 “內(nèi)存狀態(tài)與 KRaft” 的一致性，通過傳遞性原則，因此多節(jié)點(diǎn)之間的內(nèi)存狀態(tài)也是一致的；

Controller 簡版的處理時序在正確性上沒什么問題，但在性能上有所瓶頸。假設(shè)每次 KRaft 多數(shù)派確認(rèn)需要 2ms，意味著 Controller 處理請求的最大吞吐為 500 req/s。因此 Kafka 的實(shí)際處理模型中將最耗時的 KRaft 確認(rèn)這步從處理時序中移除了。具體流程如下圖所示：

圖片

相比簡版的處理時序：

Leader 的 Manager 產(chǎn)生出 Records 后立刻 #replay 更新內(nèi)存狀態(tài)，并異步提交 Records 到 KRaft，這時候就可以繼續(xù)處理下一個請求了；
響應(yīng)仍舊是 KRaft 多數(shù)派確認(rèn)后再返回；
Follower 的內(nèi)存狀態(tài)仍舊是從 KRaft Log 的 Records #replay 更新；

Controller 處理請求的最大吞吐為：Min(1s / Manager 代碼執(zhí)行 CPU 耗時, KRaft 寫入吞吐)。

然而先 #replay 到內(nèi)存再讓 KRaft 確認(rèn)可能會造成內(nèi)存里面有臟數(shù)據(jù)，仍舊以 CAS(1, 2) 舉例，考慮如下場景：

Controller Leader 的 Manager 通過 #replay 將內(nèi)存值從 1 更新成 2；
Leader 提交 Record{value=2}到 KRaft；
假設(shè)這時候由于心跳超時抖動等原因，導(dǎo)致該節(jié)點(diǎn)不再是 KRaft Leader 了，這時候會提交失敗，返回客戶端失敗；
這時 Controllers 節(jié)點(diǎn)內(nèi)存中的狀態(tài)分別為 2、1、1，KRaft 中的狀態(tài)為 1，集群狀態(tài)不一致；

為了解決這個問題，Kafka 設(shè)計(jì)了一系列支持 MVCC 的 Timeline 數(shù)據(jù)結(jié)構(gòu)：TimelineHashMap、TimelineHashSet、TimelineInteger、TimelineLong 和底層的 SnapshotRegistry。Controller 的內(nèi)存狀態(tài)都通過 Timeline 數(shù)據(jù)結(jié)構(gòu)來維護(hù)，當(dāng)出現(xiàn) Leader 切換時，舊的 Leader 會將 Timeline 數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)回滾到上一個已經(jīng)被 KRaft 多數(shù)派確認(rèn)的狀態(tài)，來保證舊 Leader 內(nèi)存中不會有臟數(shù)據(jù)。

可能細(xì)心的小伙伴會發(fā)現(xiàn)，解決了寫入的臟數(shù)據(jù)問題，那是不是可能讀到還未被 KRaft 確認(rèn)的數(shù)據(jù)呢？Timeline 數(shù)據(jù)結(jié)構(gòu)也考慮到了這點(diǎn)，例如 TimelineLong 提供了 #get(epoch) 接口，其中 epoch 通常傳入的是 KRaft CommitedOffset，以此來保障讀到的數(shù)據(jù)都是 KRaft 確認(rèn)過的數(shù)據(jù)。

對 Timeline 數(shù)據(jù)結(jié)構(gòu)有興趣的小伙伴，可以自行研究一下 server-common 模塊下 org.apache.kafka.timeline 這個包的實(shí)現(xiàn)。

2.2 Broker

在上一章節(jié)我們提到，Controller Follower 會 #replay KRaft 中的數(shù)據(jù)來構(gòu)建自己的內(nèi)存狀態(tài)。Broker 同理也一樣會訂閱 KRaft 中的 Records 來構(gòu)建自己的內(nèi)存元數(shù)據(jù)，并且根據(jù)這些 Records 來執(zhí)行特定的變更。

以分區(qū)管理為例，假設(shè)集群有 B1 和 B2 兩個節(jié)點(diǎn)，用戶將分區(qū) P1 從 B1 移動到 B2（簡化 ISR 變更的過程）：

Controller 處理分區(qū)移動請求，并生成 PartitionChangeRecord{P1=B2}提交到 KRaft；
B1 #replay到對應(yīng)的變更記錄，更新內(nèi)存元數(shù)據(jù)記錄 P1 在 B2 上，并開始關(guān)閉 P1；
B2#replay到對應(yīng)的變更記錄，更新內(nèi)存元數(shù)據(jù)記錄 P1 在 B2 上，并開始打開 P1；

這時候 B1 和 B2 都可以通過內(nèi)存元數(shù)據(jù)提供一致的的 Topic Metadata 查詢服務(wù)，并且完成了分區(qū) P1 的移動。

通過這種方式，很多變更 Controller 無需再主動調(diào)用 Broker 的 RPC 來嘗試將集群推進(jìn)到某個狀態(tài)，也無需處理 RPC 調(diào)用中的順序和冪等重試等問題。轉(zhuǎn)換思路，Controller 通過 KRaft 來下發(fā)期望的狀態(tài)，然后 Broker 去達(dá)成狀態(tài)，這和 K8s 推薦的聲明式管理有異曲同工之妙。

三、總結(jié)

我們可以看出 KRaft 替換 ZK，并不是元數(shù)據(jù)存儲重新造輪子，而核心是集群協(xié)調(diào)機(jī)制的演進(jìn)。整個通信協(xié)調(diào)機(jī)制本質(zhì)上是事件驅(qū)動模型，也就是 Metadata as an Event Log，Leader 通過 KRaft 生產(chǎn)權(quán)威的事件，F(xiàn)ollower 和 Broker 通過監(jiān)聽 KRaft 來獲得這些事件，并且順序處理事件，達(dá)到集群狀態(tài)和期望的最終一致。

參考資料

[1] KIP-500 Replace Zookeeper with a Self-Managed Metadata Quorum：https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum

[2] Timeline：https://github.com/apache/kafka/tree/trunk/server-common/src/main/java/org/apache/kafka/timeline

本文鏈接：http://www.www897cc.com/showinfo-26-92140-0.htmlKafka 如何基于 KRaft 實(shí)現(xiàn)集群最終一致性協(xié)調(diào)

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： React Native V0.74 穩(wěn)定版發(fā)布

下一篇： Python性能加速器：深度解析__slots__屬性優(yōu)化內(nèi)存利用！

標(biāo)簽：

熱門焦點(diǎn)

Mate60手機(jī)殼曝光致敬自己的經(jīng)典設(shè)計(jì)

8月3日消息，今天下午博主數(shù)碼閑聊站帶來了華為Mate60的第三方手機(jī)殼圖，可以讓我們在真機(jī)發(fā)布之前看看這款華為全新旗艦的大致輪廓。從曝光的圖片看，Mate 60背后攝像頭面積依然
對標(biāo)蘋果的靈動島華為帶來實(shí)況窗功能

繼蘋果的靈動島之后，華為也在今天正式推出了“實(shí)況窗”功能。據(jù)今天鴻蒙OS 4.0的現(xiàn)場演示顯示，華為的實(shí)況窗可以更高效的展現(xiàn)出實(shí)時通知，比如鎖屏上就能看到外賣、打車、銀行
Redmi Buds 4開箱簡評：才199還有降噪可以無腦入

在上個月舉辦的Redmi Note11T Pro系列新機(jī)發(fā)布會上，除了兩款手機(jī)新品之外，Redmi還帶來了兩款TWS真無線藍(lán)牙耳機(jī)產(chǎn)品，Redmi Buds 4和Redmi Buds 4 Pro，此前我們在Redmi Note11T
K6：面向開發(fā)人員的現(xiàn)代負(fù)載測試工具

K6 是一個開源負(fù)載測試工具，可以輕松編寫、運(yùn)行和分析性能測試。它建立在 Go 和 JavaScript 之上，它被設(shè)計(jì)為功能強(qiáng)大、可擴(kuò)展且易于使用。k6 可用于測試各種應(yīng)用程序，包括 Web
一篇文章帶你了解 CSS 屬性選擇器

屬性選擇器對帶有指定屬性的 HTML 元素設(shè)置樣式。可以為擁有指定屬性的 HTML 元素設(shè)置樣式，而不僅限于 class 和 id 屬性。一、了解屬性選擇器CSS屬性選擇器提供了一種簡單而
雅柏威士忌多款單品價格大跌，泥煤頂流也不香了？

來源 | 烈酒商業(yè)觀察編 | 肖海林今年以來，威士忌市場開始出現(xiàn)了降溫跡象，越來越多不斷暴漲的網(wǎng)紅威士忌也開始悄然回歸市場理性。近日，LVMH集團(tuán)旗下蘇格蘭威士忌品牌雅柏（Ardbeg
10天營收超1億美元，《星鐵》比《原神》差在哪？

來源：伯虎財(cái)經(jīng)作者：陳平安即便你沒玩過《原神》，你一定聽說過的它的大名。恨它的人把《原神》開服那天稱作是中國游戲史上最黑暗的一天，有粉絲因?yàn)樗髂嵩赑S平臺上線《原神》，怒而
2納米決戰(zhàn)2025

集微網(wǎng)報(bào)道從三強(qiáng)爭霸到四雄逐鹿，2nm的廝殺聲已然隱約傳來。無論是老牌勁旅臺積電、三星，還是誓言重回先進(jìn)制程領(lǐng)先地位的英特爾，甚至初成立不久的新
Windows 11發(fā)布，微軟一改往常對老機(jī)型開放的態(tài)度

距離 Windows 11 發(fā)布已經(jīng)過去一周，在過去一周里，很多數(shù)碼愛好者圍繞其對 Android 應(yīng)用的支持、對老機(jī)型的升級問題展開了激烈討論。與以往不同的是，在這次大

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

Kafka 如何基于 KRaft 實(shí)現(xiàn)集群最終一致性協(xié)調(diào)

一、架構(gòu)概覽

二、最終一致性協(xié)調(diào)

2.1 Controller

2.2 Broker

三、總結(jié)

Mate60手機(jī)殼曝光致敬自己的經(jīng)典設(shè)計(jì)

對標(biāo)蘋果的靈動島華為帶來實(shí)況窗功能

Redmi Buds 4開箱簡評：才199還有降噪可以無腦入

K6：面向開發(fā)人員的現(xiàn)代負(fù)載測試工具

一篇文章帶你了解 CSS 屬性選擇器

雅柏威士忌多款單品價格大跌，泥煤頂流也不香了？

10天營收超1億美元，《星鐵》比《原神》差在哪？

2納米決戰(zhàn)2025

Windows 11發(fā)布，微軟一改往常對老機(jī)型開放的態(tài)度

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊