微服務：5-zookeeper 選舉機制
zookeeper 選舉機制
1 zk叢集核心之三種角色
-
leader 整個叢集zk寫請求的唯一處理者，並負責進行投票的發起和決議，更新系統狀態
-
follower 接收客戶端請求，處理讀請求，並向客戶端返回結果；將寫請求轉給Leader；在選舉Leader過程參與投票
-
observer 無選舉投票權的follower，主要協助follower處理更多的讀請求
- 如果叢集的讀請求負載很高，或者客戶端非常多，多到跨機房，則可以設定一些Observer伺服器，以提高讀取的吞吐量
2 zk註冊中心常見的三種模式
-
zk的核心是廣播機制，保證各個zk之間資料同步,zk實現的機制為ZAB協議
-
恢復模式: 如果Leader崩潰，這個時候就會進入恢復模式，使整個zk叢集恢復到正常的工作狀態
-
同步模式: 新的Leader選舉出來後，就進入同步模式(各個follower會去同步新的Leader上的資料)，當大多數zkServer完成了與Leader狀態同步後，恢復模式就結束
-
廣播模式：客戶端想寫入資料，整個時候Leader發起提議，當Leader的提議被大多數的zkServer統一之後，Leader就會去修改自身的資料，並將修改後的資料廣播給
其他的follower
-
myid
伺服器唯一標識，如有三個zk伺服器，編號分別： 1，2，3
-
zxid
ReentranReaderWriteLock 32位
-
zxid位long型別，高32位epoch,低32位表示xid，即zxid由兩部分構成
-
每個Leader都會具有個不同的epoch值，表示一個時期、時代。新的Leader產生，則會更新所有
的zkServer的zxid中的epoch。 -
而xid為zk的事務id，每個寫操作都是一個事務，都會有個xid。
-
每個寫操作都需要由Leader發起一個提議，由所有Follower表決是否同意本次寫操作
-
-
邏輯時鐘
一個整型數，在選舉時成為logical lock。在zxid中則為epoch值。
epoch與logical lock是同一個值，在不同情況下的不同名稱。 -
zk的選舉狀態
LOOKING: 選舉狀態(查詢Leader的狀態)
LEADING: 領導者狀態,處於該狀態的伺服器稱為Leader
FOLLOWING: 隨從狀態，同步leader狀態，處於該狀態的伺服器稱為Flollower
OBSERVING: 觀察狀態，同步leader狀態，處於該狀態的伺服器稱為Observer
4 zk叢集選舉發生的時機和選舉演算法
-
發生時機： 整個叢集群龍無首的時候
- 服務啟動
- leader宕機之後
-
選舉機制
- 叢集中，半數zkServer同意，則產生新的leader
- 搭建叢集時，一般是奇數個，半數以上同意產生leader
三臺伺服器，最多允許一臺宕機
四臺伺服器，也是最多允許一臺宕機
-
選舉演算法
- 對比(myid,zxid),先對比zxid，zxid大(資料越新)勝出，成為leader
- 如果zxid一致，則myid大者成為leader
如：
服務啟動：有三臺myid = 1,2,3
myid=1 啟動後，給自己投票，釋出投票結果(myid,zxid) myid=2 啟動，同樣給自己投票，跟第一臺比較，zxid一樣，則比較myid，誰大，誰勝出宕機時
若leader宕機，此時活著的server將會修改狀態為looking 哪個服務的zxid比較大，則勝出leader
5 叢集搭建
-
埠作用
- 2181 對client端提供服務
- 2888 叢集及其通訊使用的埠
- 3888 叢集選舉leader
-
修改zk配置
-
編輯zk下conf目錄下zoo.cfg
修改
dataDir = /opt/apache-zookeeper-3.6.2-bin/data
新增
server.1=slave1:2888:3888
server.2=slave2:2888:3888 -
給集權伺服器，分別新增使用者
useradd = zookeeper -
在zk下的data目錄下新增myid檔案，內容為數字，對應server.1=slave1裡的數字1
-
將三臺伺服器的zk的許可權，都賦給zookeeper使用者
chown -R zookeeper:zookeeper apache-zookeeper-3.6.2-bin/ -
關閉防火牆
systemctl stop firewalld.service -
進入zk的bin目錄
rm -rf *.cmd
chmod +x *.sh -
依次啟動
./zkServer.sh start -
檢視狀態
./zkServer.sh status
-