當前位置：首頁 > 科技 > 軟件

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

來源：責編：時間：2024-06-05 17:44:34 148觀看

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

一、架構概覽

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

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

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

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

圖片

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

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

在 KRaft 模式下：

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

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

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

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

2.1 Controller

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

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

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

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

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

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

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

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

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

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

圖片

相比簡版的處理時序：

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

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

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

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

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

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

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

2.2 Broker

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

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

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

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

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

三、總結

我們可以看出 KRaft 替換 ZK，并不是元數(shù)據存儲重新造輪子，而核心是集群協(xié)調機制的演進。整個通信協(xié)調機制本質上是事件驅動模型，也就是 Metadata as an Event Log，Leader 通過 KRaft 生產權威的事件，F(xiàn)ollower 和 Broker 通過監(jiān)聽 KRaft 來獲得這些事件，并且順序處理事件，達到集群狀態(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.tebozhan.com/showinfo-26-92140-0.htmlKafka 如何基于 KRaft 實現(xiàn)集群最終一致性協(xié)調

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

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

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

標簽：

熱門焦點

小紅書1周漲粉49W+，我總結了小白可以用的N條漲粉筆記

作者：黃河懂運營一條性教育視頻，被54萬人“珍藏”是什么體驗？最近，情感博主@公主是用鮮花做的，火了！僅僅憑借一條視頻，光小紅書就有超過128萬人，為她瘋狂點贊！更瘋狂的是，這
中國家電海外掘金正當時｜出海專題

作者｜吳南南編輯｜胡展嘉運營｜陳佳慧出品｜零態(tài)LT（ID：LingTai_LT）2023年，出海市場戰(zhàn)況空前，中國創(chuàng)業(yè)者在海外紛紛摩拳擦掌，以期能夠把中國的商業(yè)模式、創(chuàng)業(yè)理念、戰(zhàn)略打法輸出海外，他們依
自律，給不了Keep自由！

來源 | 互聯(lián)網品牌官作者 | 李大為編排 | 又耳審核 | 谷曉輝自律能不能給用戶自由暫時不好說，但大概率不能給Keep自由。近日，全球最大的在線健身平臺Keep正式登陸港交所，努力
三星電子Q2營收60萬億韓元存儲業(yè)務營收同比仍下滑超過50%

7月27日消息，據外媒報道，從三星電子所發(fā)布的財報來看，他們主要利潤來源的存儲芯片業(yè)務在今年二季度仍不樂觀，營收同比仍在大幅下滑，所在的設備解決方案
三星推出Galaxy Tab S9系列平板電腦以及Galaxy Watch6系列智能手表

2023年7月26日，三星電子正式發(fā)布了Galaxy Z Flip5與Galaxy Z Fold5。除此之外，Galaxy Tab S9系列平板電腦以及三星Galaxy Watch6系列智能手表也同期
AMD的AI芯片轉單給三星可能性不大與臺積電已合作至2nm制程

據 DIGITIMES 消息，英偉達 AI GPU 出貨逐季飆升，接下來 AMD MI 300 系列將在第 4 季底量產。而半導體業(yè)內人士表示，近日傳出 AMD 的 AI 芯片將轉單給
超級標準版旗艦！iQOO 11S全球首發(fā)iQOO超算獨顯芯片

上半年已接近尾聲，截至目前各大品牌旗下的頂級旗艦都已悉數(shù)亮相，而下半年即將推出的頂級旗艦已經成為了數(shù)碼圈爆料的主流，其中就包括全新的iQOO 11S系
2299元起！iQOO Pad明晚首銷：性能最強天璣平板

5月23日，iQOO如期舉行了新品發(fā)布會，除了首發(fā)安卓最強旗艦處理器的iQOO Neo8系列新機外，還在發(fā)布會上推出了旗下首款平板電腦——iQOO Pad，其最大的賣點
首發(fā)天璣9200+ iQOO Neo8系列發(fā)布首銷售價2299元起

2023年5月23日晚，iQOO Neo8系列正式發(fā)布。其中，Neo系列首款Pro之作——iQOO Neo8 Pro強悍登場，限時售價3099元起；價位段最強性能手機iQOO Neo8同期上市

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

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

一、架構概覽

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

2.1 Controller

2.2 Broker

三、總結

小紅書1周漲粉49W+，我總結了小白可以用的N條漲粉筆記

中國家電海外掘金正當時｜出海專題

自律，給不了Keep自由！

三星電子Q2營收60萬億韓元存儲業(yè)務營收同比仍下滑超過50%

三星推出Galaxy Tab S9系列平板電腦以及Galaxy Watch6系列智能手表

AMD的AI芯片轉單給三星可能性不大與臺積電已合作至2nm制程

超級標準版旗艦！iQOO 11S全球首發(fā)iQOO超算獨顯芯片

2299元起！iQOO Pad明晚首銷：性能最強天璣平板

首發(fā)天璣9200+ iQOO Neo8系列發(fā)布首銷售價2299元起

最新推薦

猜你喜歡

熱門推薦

相關資訊