前言
本文是根據螞蟻課堂余勝軍老師的課程所做筆記，記錄的要點，部分自己的理解可能有所偏差，不當之處會進行修改。
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采用日志復制形式同步數據
- 所有的寫請求都交給領導者，將請求操作寫入日志，標記該狀態為未提交狀態。
- 為了提交該日志，領導者就會將日志以心跳形式發送給其他跟隨者，只要滿足過半的跟隨者可以寫入該數據，則直接通知其他節點同步該數據，這個過程稱為日志復制。