分散式系統調取服務架構圖

CAP原則【三選二】

• C：一致性（consistency）:在分散式系統中的所有資料備份，在同一時刻是否是同樣的值（等同於所有節點訪問同一份最新的資料副本）
• A：可用性（Availability）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
• P：分割槽容錯性（Partition tolerance）：以實際效果而言，分割槽相當於***對通訊的時限要求***。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。

BASE原則【CAP的折中】

• BA:：基本可用（Basically Available）
• S：軟狀態（Soft State）
• E：最終一致性（Evebtual Consistency）

C、A、P三個都要，但不用100%的保證每一個原則 分散式肯定是優先保證P，多數時候是在C和A之間做權衡選擇。

常用的分散式系統的權衡：

（1）、MySQL 單機（CA）

（2）、Eureka叢集（AP）：保證可用性作為首要條件。Eureka各個節點都是平等的，幾個節點掛了不會影響其它正常的節點工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的資訊可能不是最新的（不保證強一致）。其中說明了，eureka是不滿足強一致性的，但是還是會保證最終一致性。

（3）、zookeeper 叢集（CP）：zookeeper在選舉leader時，會停止服務，直到選舉成功之後才會再次對外提供服務，這個時候就說明了服務不可用，但是在選舉成功之後，因為一主多從的結構，zookeeeper在這時還是一個高可用註冊中心，只是在優先保證一致性的前提下，zookeeper才會顧及到可用性。

（4）、nacos 叢集（AP或CP）：預設使用AP模型，但也支援CP模型。Nacos不只是發現中心，也是配置中心（配置中心一致性是資料庫保證的），以後可能也會有更遠大的設計目標，需要保證資料的強一致性。

（5）、redis 叢集（AP）：AP模型保證了分散式系統的高可用性。AP模型的分散式鎖基於Redis來實現，使用於對資料的一致性要求不那麼苛刻的場景中，可以保證高可用性。根據redis的儲存結構以及原理可以知道redis無法保證主從節點資料的一致性，無法保證在主節點宕機時將所有資料自動同步到從節點中，因此在業務要求保證一致性的場景中，redis的分散式鎖會在主節點宕機的情況下丟失鎖資訊而出現重複上鎖的極端情況。

redis分散式鎖的最致命的問題就是無法保證資料的一致性，如果一旦主節點宕機，資料沒有同步到從節點，會出現再次上鎖的問題。如果業務一定需要資料的一致性在高併發的場景下是不建議選擇redis鎖的實現，可以選擇CP模型的Zookeeper或etcd來實現分散式鎖。

（6）、RocketMQ 中介軟體（AP）：自己實現了一個服務治理服務NameServer,它採用了AP模型，原因是它只是個服務治理服務，它的實現相對簡陋，應該說相當簡潔，所以效率也相當的高。