這篇文章主要介紹“Kafka可用架構有哪些”，在日常操作中，相信很多人在Kafka可用架構有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kafka可用架構有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

網站建設哪家好，找創新互聯！專注于網頁設計、網站建設、微信開發、微信平臺小程序開發、集團企業網站建設等服務項目。為回饋新老客戶創新互聯還提供了改則免費建站歡迎大家使用！

Controller選舉

當添加一個分區或分區增加副本的時候，都要從所有副本中選舉一個新的Leader出來。

Leader如果選舉？投票怎么玩？是不是所有的partition副本直接發起投票，開始競選呢？比如用ZK實現。

利用ZK如何實現選舉？ZK的什么功能可以感知到節點的變化（增加或減少）？或者說ZK為什么能實現加鎖和釋放鎖？

用到了3個特點：watch機制；節點不允許重復寫入；臨時節點。

這樣實現是比較簡單，但也會存在一定弊端。如果分區和副本數量過多，所有的副本都直接選舉的話，一旦某個節點增減，就會造成大量watch事件被觸發，ZK的負載就會過重。

kafka早期的版本就是這樣做的，后來換了一種實現方式。

不是所有的repalica都參與leader選舉，而是由其中的一個Broker統一來指揮，這個Broker的角色就叫做Controller（控制器）。

就像redis Sentinel的架構，執行故障轉移的時候，必須要先從所有哨兵中選一個負責故障轉移的節點一樣。kafka 也要先從所有Broker中選出唯一的一個Controller。

所有Broker會嘗試在zookeeper中創建臨時節點/controller，只有一個能創建成功（先到先得）。

如果Controller掛掉了或者網絡出現了問題，ZK上的臨時節點會消失。其他的Brokder通過watch監聽到Controller下線的消息后，開始競選新的Controller。方法跟之前還是一樣的，誰先在ZK里寫入一個/cotroller節點，誰就成為新的Controller。

成為Controller節點之后，它的責任也比其他節點重了幾分：

1. 監聽Broker變化

2. 監聽Topic變化

3. 監聽Partition變化

4. 獲取和管理Broker、Topic、Partition的信息

5. 管理Partiontion的主從信息

分區副本Leader選舉

Controller確定以后，就可以開始做分區選主的事了。下面就是找候選人了。顯然，每個replica都想推薦自己，但所有的replica都有競選資格嗎？并不是，這里有幾個概念。

Assigned-Replicas（AR）：一個分區的所有副本。 In-Sync Replicas(ISR)：上邊所有副本中，跟leader數據保持一定程度同步的。 Out-Sync Replicas(OSR)：跟leader同步滯后過多的副本。

AR=ISR + OSR。正常情況下OSR是空的，大家正常同步，AR=ISR。

誰能參加選舉？肯定不是AR，也不是OR，而是ISR。而且這個ISR不是固定不變的，還是一個動態列表。

前面說過，如果同步延遲超30秒，就踢出ISR，進入OSR；如果趕上來了就加入ISR。

默認情況下，當leader副本發生故障時，只有在ISR集合中的副本才有資格被選舉為新的leader。

如果ISR為空呢？群龍不能無首。在這種情況下，可以讓ISR之外的副本參與選舉。允許ISR之外的副本參與選舉，叫做unclean leader election。

unclean.leader.election.enable=false

把這個參數改成true(一般不建議開啟，會造成數據丟失)。

Controller有了，候選人也有了ISR，那么根據什么規則確定leader呢？

我們首先來看分布式系統中常見的選舉協議有哪些（或者說共識算法）？

ZAB（ZK）、Raft（Redis Sentinel）他們都是Paxos算法的變種，核心思想歸納起來都是：先到先得、少數服從多數。

但kafka沒有用這些方法，而是用了一種自己實現的算法。

為什么呢？比如ZAB這種協議，可能會出現腦裂（節點不能互通的時候，出現多個leader）、驚群效應（大量watch事件被觸發）。

在文檔中有說明：

https://kafka.apachecn.org/documentation.html#design_replicatedlog

提到kafka的選舉實現，最相近的是微軟的PacificA算法。

在這種算法中，默認是讓ISR中第一個replica變成leader。像中國皇帝傳位一樣，優先傳給皇長子。

主從同步

leader確定之后，客戶端的讀寫只能操作leader節點。follower需要向leader同步數據。

不同的raplica的offset是不一樣的，同步到底怎么同步呢？

在之后內容，需要先理解幾個概念。

LEO（Log End Offset）：下一條等待寫入的消息的offset（最新的offset + 1）。

HW（Hign Watermark 高水位）：ISR中最小的LEO。Leader會管理所有ISR中最小的LEO為HW。

consumer最多只能消費到HW之前的位置。也就是說，其他副本沒有同步過去的消息，是不能被消費的。

kafka為什么這么設計？

如果在同步成功之前就被消費了，consumer group 的offset會偏大，如果leader崩潰，中間會丟失消息。

接著再看消息是如何同步的。

Replica 1與Replica2各同步了1條數據，HW推進了1，變成了7，LEO因Replica2推進了1，變成了7。

Replica 1與Replica2各同步了2條數據，HW和LEO重疊，都到了9。

在這需要了解一下，從節點如何與主節點保持同步？

1. follower節點會向Leader發送一個fetch請求，leader向follower發送數據后，即需要更新follower的LEO。

2. follower接收到數據響應后，依次寫入消息并且更新LEO。

3. leader更新HW（ISR最小的LEO）

kafka設計了獨特的ISR復制，可以在保障數據一致性情況下又可以提供高吞吐量。

Replica故障處理

follower故障

首先follower發生鼓掌，會被先踢出ISR。

follower恢復之后，從哪開始同步數據呢？

假設Replica1宕機。

恢復以后，首先根據之前的記錄的HW（6），把高于HW的消息截掉（6、7）。

然后向Leader同步消息。追上Leader之后（30秒），重新加入ISR。

leader故障

還以上圖為例，如果圖中Leader發生故障。

首先選一個Leader，因為Replica1優先，它將成為Leader。

為了保證數據一致，其他follower需要把高于HW的消息截掉（這里沒有消息需要截?。?。

然后Replica2同步數據。

此時原Leader中的數據8將丟失。

注意：這種機制只能保證副本之間的數據一致性，并不能保證數據不丟失或者不重復。

到此，關于“Kafka可用架構有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注創新互聯網站，小編會繼續努力為大家帶來更多實用的文章！