前言

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

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隨機數一樣的處理方式

如果所有節點的超時隨機數都是一樣的情況下，當前投票全部作廢，重新生成超時時間。
如果多個節點生成的隨機數一樣，得票高的為領導者。如果票數完全一樣，直接作廢。

集群節點建議為奇數。

Raft故障重新選舉

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

Raft采用日志復制形式同步數據

所有的寫請求都交給領導者，將請求操作寫入日志，標記該狀態為未提交狀態。
為了提交該日志，領導者就會將日志以心跳形式發送給其他跟隨者，只要滿足過半的跟隨者可以寫入該數據，則直接通知其他節點同步該數據，這個過程稱為日志復制。

總結

以上是生活随笔為你收集整理的五、Nacos集群部署实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。