淺談Nacos中的CAP
每天多學一點點~
話不多說，這就開始吧…
1.前言
說起CAP原則，大家都不陌生。只要是個分布式系統，都應該滿足。之前寫過Zk的CAP，今天來談談nacos中是如何實現CAP的。
Zookeeper集群選舉機制以及數據同步機制
Nacos源碼環境搭建和源碼流程圖
2.CAP理論和BASE理論
CAP原則又稱CAP定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
分布式系統的CAP理論：理論首先把分布式系統中的三個特性進行了如下歸納：
- 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
- 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容錯性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
一般分布式系統中，肯定是優先辦證P，剩下的就是C和A的取舍。
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分布式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。
簡單來說BASE就是CAP的折中，C A P我三個都要，但不用100%保證每一次原則。
3.Nacos中的CAP
首先，nacos保證了P，官方推薦使用A，即AP，保證其高可用。而與之典型的幾個注冊中心
- zookeeper(CP 集群leader掛了會重新選舉，此時暫停對外服務)。
- mysql(單機版CA)
- eureka集群(AP)
- eureka集群(AP)
- redis集群(AP)
看過ribbon源碼可知，如果發現連接失敗，則會自動切換至其他的節點，只要有一台還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證一致性）
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊時如果發現連接失敗，則會自動切換至其他的節點，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
1.Eureka不再從注冊列表中移除因為長時間沒有收到心跳而應該過期的服務
2.Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）
3.當前網絡穩定時，當前實例新的注冊信息會被同步到其它節點中 因此，Eureka可以很好的應對因網絡故障導致節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。
而nacos和eureka和類似，上文也說過，有服務健康檢查和心跳機制，具體請看上一張源碼流程圖分析。
4.Nacos中AP模式源碼分析
5.常見的面試題
- 什么是腦裂：
集群（M-S的情況）通常是發生在節點通信不可達(分區)的情況下，集群會分裂成不同的小集群，小集群各自選舉出多個master節點的情況。 - nacos和zookeeper是如何避免腦裂的？
leader選舉，要求節點的投票數量>總節點數量/2，即過半數，有這個選舉原則保證了集群出現分區，無論如何最多只能有一個小集群選出leader。 - M-S 模式的集群節點個數為何推薦是奇數個？
首先，偶數個節點的集群一旦出現對半分區(比如4個節點分區成兩個節點和兩個節點的情況)，整個集群無法選舉出leader，集群無法提供服務。
其次，在容錯能力相同的情況下，奇數節點比偶數節約資源。比如，5個節點掛了2個還能選出leader，而6個節點最多也只能掛2個節點才能保證選舉出leader。