Kafka Partition Leader選主機制

Kafka Partition Leader選主機制
更多幹貨
分佈式實戰（乾貨）
spring cloud 實戰（乾貨）
mybatis 實戰（乾貨）
spring boot 實戰（乾貨）
React 入門實戰（乾貨）
構建中小型互聯網企業架構（乾貨）
python 學習持續更新
ElasticSearch 筆記
kafka storm 實戰 (乾貨)
1、概述
大數據經常使用的選主機制
經常使用選主機制的缺點
Kafka Partition選主機制
2、大數據經常使用的選主機制
Leader選舉算法很是多，大數據領域經常使用的有 如下兩種:

Zab(zookeeper使用);
Raft； ……
它們都是Paxos算法的變種。

Zab協議有四個階段:

Leader election;
Discovery（或者epoch establish）；
Synchronization（或者sync with followers）
Broadcast
好比3個節點選舉leader，編號爲1,2,3。1先啓動，選擇本身爲leader，而後2啓動首先也選擇本身爲 leader，因爲1,2都沒過半，選擇編號大的爲leader，因此1,2都選擇2爲leader,而後3啓動發現1,2已經協商好且數量過半，因而3也選擇2爲leader，leader選舉結束。

在Raft中，任什麼時候候一個服務器能夠扮演下面角色之一

Leader: 處理全部客戶端交互，日誌複製等，通常只有一個Leader；
Follower: 相似選民，徹底被動
Candidate候選人: 能夠被選爲一個新的領導人
啓動時在集羣中指定一些機器爲Candidate ，而後Candidate開始向其餘機器(尤爲是Follower)拉票，當某一個Candidate的票數超過半數，它就成爲leader。

經常使用選主機制的缺點

因爲Kafka集羣依賴zookeeper集羣，因此最簡單最直觀的方案是，全部Follower都在ZooKeeper上設置一個Watch，一旦Leader宕機，其對應的ephemeral znode會自動刪除，此時全部Follower都嘗試建立該節點，而建立成功者（ZooKeeper保證只有一個能建立成功）便是新的Leader，其它Replica即爲Follower。

前面的方案有如下缺點：

split-brain (腦裂): 這是由ZooKeeper的特性引發的，雖然ZooKeeper能保證全部Watch按順序觸發，但並不能保證同一時刻全部Replica「看」到的狀態是同樣的，這就可能形成不一樣Replica的響應不一致 ;

herd effect (羊羣效應): 若是宕機的那個Broker上的Partition比較多，會形成多個Watch被觸發，形成集羣內大量的調整；

ZooKeeper負載太重 : 每一個Replica都要爲此在ZooKeeper上註冊一個Watch，當集羣規模增長到幾千個Partition時ZooKeeper負載會太重

3、Kafka Partition選主機制
Kafka 的Leader Election方案解決了上述問題，它在全部broker中選出一個controller，全部Partition的Leader選舉都由controller決定。controller會將Leader的改變直接經過RPC的方式（比ZooKeeper Queue的方式更高效）通知需爲此做爲響應的Broker。

Kafka 集羣controller的選舉過程以下 ：

每一個Broker都會在Controller Path (/controller)上註冊一個Watch。

當前Controller失敗時，對應的Controller Path會自動消失（由於它是ephemeral Node），此時該Watch被fire，全部「活」着的Broker都會去競選成爲新的Controller（建立新的Controller Path),可是隻會有一個競選成功（這點由Zookeeper保證）。

競選成功者即爲新的Leader，競選失敗者則從新在新的Controller Path上註冊Watch。由於Zookeeper的Watch是一次性的，被fire一次以後即失效，因此須要從新註冊。

Kafka partition leader的選舉過程以下 (由controller執行)：

從Zookeeper中讀取當前分區的全部ISR(in-sync replicas)集合 調用配置的分區選擇算法選擇分區的leader