5、Nacos集羣部署實現原理

前言

本文是根據螞蟻課堂餘勝軍老師的課程所作筆記，記錄的要點，部分本身的理解可能有所誤差，不當之處會進行修改。

CAP原則

CPA即一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP三個要素不可能所有實現，最多實現兩個。通常的實際都是基於AP和CP。

而Nacos支持CP/AP兩個模式和混合模式，能夠進行切換，默認爲AP。

Eureka與Zookeeper的區別

都是分佈式服務註冊中心。

zookeeper採用CP保證數據一致性，原理採用Zab原子廣播協議，當zk集羣的leader宕機後，會自動從新選擇一個新的領導角色，在選舉過程當中，zk環境不可以使用。zk可運行的節點必須過半才能使用。

Eureka採用AP設計，徹底去中心化。各個節點之間相互註冊，只要有一個節點，整個微服務就能夠通信。

Eureka與Nacos的區別

Eureka採用AP模式

Nacos採用AP+CP模式混合實現，默認爲AP。

Eureka底層實現集羣協議是去中心化對等，Nacos使用Raft協議會產生領導角色。

分佈式系統一致性算法

分佈式系統一致性算法是用來保證集羣節點的數據一致性的問題。

有raft（nacos）、zab（zookeeper）、paxos等。

Zab協議集羣模式原理

Zab是中心化思想的集羣模式，zookeeper採用的即是此協議。

zookeeper爲了保持數據一致性，須要知足大多數狀況，即多數節點可用時集羣才能工做，>n/2+1個節點可用。

在zookeeper集羣中有領導者和跟隨者，對每一個結點有比較其能力的myid值，根據能力值的大小選擇出領導者。不過一旦啓動的可用節點過半後選擇出了領導者後，就不會再選舉領導者了，除非當前領導者宕機。

Zab數據一致性

全部的寫請求統一交給領導角色實現，領導角色寫完數據以後，領導角色再將數據同步給每一個節點。

數據同步採用2pc兩階段提交協議

如上圖，先去比較zxid的大小，將zxid大的做爲領導角色。若是zxid相同，則比較myid，myid大的做爲領導者。

每次寫入數據時，領導角色會攜帶上本身zxid去詢問跟隨者，如有過半的跟隨者回應，則進行寫入操做，並將領導者的zxid寫給同步的跟隨者。

Raft協議選舉實現原理

Raft協議中有三種狀態：跟隨者、競選者、領導者。

默認狀況下每一個節點都是跟隨者，每一個節點會隨機生成一個選舉的超時時間，在這個超時的時間範圍類節點必需要等待。

超時時間事後，當前結點有跟隨者變爲競選者，會給其餘發出選舉的投票通知，只要該競選者有超過半數以上便可成爲領導者。

超時時間短的成爲領導者的可能大。

Raft隨機數同樣的處理方式

1. 若是全部節點的超時隨機數都是同樣的狀況下，當前投票所有做廢，從新生成超時時間。
2. 若是多個節點生成的隨機數同樣，得票高的爲領導者。若是票數徹底同樣，直接做廢。

集羣節點建議爲奇數。

Raft故障從新選舉

若是跟隨者節點不能及時收到領導角色的消息，那麼跟隨者就會變爲競選者，給其餘節點發送選舉投票通知，有過半票數則稱爲領導者。

Raft採用日誌複製形式同步數據

1. 全部的寫請求都交給領導者，將請求操做寫入日誌，標記該狀態爲未提交狀態。
2. 爲了提交該日誌，領導者就會將日誌以心跳形式發送給其餘跟隨者，只要知足過半的跟隨者能夠寫入該數據，則直接通知其餘節點同步該數據，這個過程稱爲日誌複製。