1. CAP 理論概述：

C（Consistency，一致性）：所有節(jié)點(diǎn)的數(shù)據(jù)是一致的，即對(duì)某個(gè)數(shù)據(jù)的所有操作，最終會(huì)傳播到集群中的每一個(gè)節(jié)點(diǎn)，保證所有節(jié)點(diǎn)的數(shù)據(jù)一致。
A（Availability，可用性）：每個(gè)請(qǐng)求都會(huì)收到一個(gè)響應(yīng)，成功或者失敗，但不至于長時(shí)間掛起。
P（Partition tolerance，分區(qū)容忍性）：系統(tǒng)能夠在某些節(jié)點(diǎn)或網(wǎng)絡(luò)發(fā)生故障時(shí)，繼續(xù)提供服務(wù)，不會(huì)因?yàn)榫W(wǎng)絡(luò)分區(qū)而宕機(jī)。

在 CAP 理論 中，系統(tǒng)最多只能保證 兩個(gè) 特性（Consistency、Availability、Partition tolerance）中的 任意兩個(gè)，不能同時(shí)保證三個(gè)特性。在分布式系統(tǒng)中，由于 分區(qū)容忍性 是不可避免的（例如網(wǎng)絡(luò)故障），所以大多數(shù)分布式系統(tǒng)會(huì)在 一致性 和 可用性 之間做選擇。

RPC 服務(wù)注冊(cè)/發(fā)現(xiàn)過程簡述如下：

服務(wù)提供者啟動(dòng)時(shí)，會(huì)將其服務(wù)名稱，IP 地址注冊(cè)到配置中心。

服務(wù)消費(fèi)者在第一次調(diào)用服務(wù)時(shí)，會(huì)通過注冊(cè)中心找到相應(yīng)的服務(wù)的 IP 地址列表，并緩存到本地，以供后續(xù)使用。

當(dāng)消費(fèi)者調(diào)用服務(wù)時(shí)，不會(huì)再去請(qǐng)求注冊(cè)中心，而是直接通過負(fù)載均衡算法從 IP 列表中取一個(gè)服務(wù)提供者的服務(wù)器調(diào)用服務(wù)。

當(dāng)服務(wù)提供者的某臺(tái)服務(wù)器宕機(jī)或下線時(shí)，相應(yīng)的 IP 會(huì)從服務(wù)提供者 IP 列表中移除。同時(shí)，注冊(cè)中心會(huì)將新的服務(wù) IP 地址列表發(fā)送給服務(wù)消費(fèi)者機(jī)器，緩存在消費(fèi)者本機(jī)。

當(dāng)某個(gè)服務(wù)的所有服務(wù)器都下線了，那么這個(gè)服務(wù)也就下線了。

同樣，當(dāng)服務(wù)提供者的某臺(tái)服務(wù)器上線時(shí)，注冊(cè)中心會(huì)將新的服務(wù) IP 地址列表發(fā)送給服務(wù)消費(fèi)者機(jī)器，緩存在消費(fèi)者本機(jī)。

服務(wù)提供方可以根據(jù)服務(wù)消費(fèi)者的數(shù)量來作為服務(wù)下線的依據(jù)。

Nacos 集群

Leader 和 Follower 節(jié)點(diǎn)：

Nacos 集群采用了類似 Raft 協(xié)議的機(jī)制，集群中的一個(gè)節(jié)點(diǎn)被選舉為 Leader，其負(fù)責(zé)處理寫請(qǐng)求（如數(shù)據(jù)的更新、注冊(cè)服務(wù)等），其他節(jié)點(diǎn)為 Follower，主要負(fù)責(zé)響應(yīng)讀請(qǐng)求（如查詢服務(wù)列表等）。
Leader 節(jié)點(diǎn)通過心跳與 Follower 節(jié)點(diǎn)保持同步，確保數(shù)據(jù)一致性。Follower 節(jié)點(diǎn)如果與 Leader 節(jié)點(diǎn)失去連接，可能會(huì)被選舉為新的 Leader。

數(shù)據(jù)同步：

集群中的節(jié)點(diǎn)之間會(huì)通過 數(shù)據(jù)同步 保持?jǐn)?shù)據(jù)的一致性。所有的寫操作（如服務(wù)注冊(cè)、配置更新等）都會(huì)先寫入 Leader 節(jié)點(diǎn)，并通過 Raft 協(xié)議同步到其他 ##Follower 節(jié)點(diǎn)。
一旦數(shù)據(jù)同步完成，集群中所有節(jié)點(diǎn)的數(shù)據(jù)保持一致。
服務(wù)發(fā)現(xiàn)和配置管理：

Nacos 集群中的所有節(jié)點(diǎn)都可以提供 服務(wù)發(fā)現(xiàn) 和 配置管理 功能，任何一個(gè)節(jié)點(diǎn)的客戶端都可以向集群中的任意節(jié)點(diǎn)發(fā)起請(qǐng)求，集群節(jié)點(diǎn)會(huì)通過負(fù)載均衡將請(qǐng)求路由到合適的節(jié)點(diǎn)。
但是，寫操作（如服務(wù)注冊(cè)、配置更新）會(huì)通過 Leader 節(jié)點(diǎn)進(jìn)行，而讀取操作（如獲取配置、查詢服務(wù)）可以從任何節(jié)點(diǎn)讀取。

心跳與故障恢復(fù)：

集群節(jié)點(diǎn)之間通過定期的 心跳機(jī)制 維持健康狀態(tài)。一旦某個(gè)節(jié)點(diǎn)不可用，其他節(jié)點(diǎn)會(huì)嘗試進(jìn)行 Leader 選舉，保證集群的高可用性。
集群規(guī)模與擴(kuò)展：

在 Nacos 集群中，節(jié)點(diǎn)可以橫向擴(kuò)展，增加新的節(jié)點(diǎn)以提升集群的處理能力和容錯(cuò)性。每個(gè)新加入的節(jié)點(diǎn)都會(huì)通過心跳機(jī)制與其他節(jié)點(diǎn)同步狀態(tài)。

總結(jié)來說，Nacos 集群中的節(jié)點(diǎn)通過 Leader 和 Follower 的角色劃分、數(shù)據(jù)同步機(jī)制、心跳檢測(cè)等方式共同保障集群的高可用性、數(shù)據(jù)一致性和負(fù)載均衡能力。

ZooKeeper

ZooKeeper Atomic Broadcast（ZAB，ZooKeeper 原子消息廣播協(xié)議）是 ZooKeeper 實(shí)現(xiàn)分布式數(shù)據(jù)一致性的核心算法。
Zookeeper客戶端會(huì)隨機(jī)的鏈接到Zookeeper集群中的一個(gè)節(jié)點(diǎn)，如果是讀請(qǐng)求，就直接從當(dāng)前節(jié)點(diǎn)中讀取數(shù)據(jù)；如果是寫請(qǐng)求，那么節(jié)點(diǎn)就會(huì)向Leader提交事務(wù)，Leader接收到事務(wù)提交，會(huì)廣播該事務(wù)，只要超過半數(shù)節(jié)點(diǎn)寫入成功，該事務(wù)就會(huì)被提交。

Zookeeper 作為注冊(cè)中心的一些弊端

作為一個(gè)分布式協(xié)同服務(wù)，ZooKeeper 非常好，但是對(duì)于 Service 發(fā)現(xiàn)服務(wù)來說就不合適了，因?yàn)閷?duì)于 Service 發(fā)現(xiàn)服務(wù)來說就算是返回了包含不實(shí)的信息的結(jié)果也比什么都不返回要好。

所以當(dāng)向注冊(cè)中心查詢服務(wù)列表時(shí)，我們可以容忍注冊(cè)中心返回的是幾分鐘以前的注冊(cè)信息，但不能接受服務(wù)直接 down 掉不可用。

但是 zk 會(huì)出現(xiàn)這樣一種情況，當(dāng) master 節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時(shí)，剩余節(jié)點(diǎn)會(huì)重新進(jìn)行 leader 選舉。

問題在于，選舉 leader 的時(shí)間太長，30 ~ 120s, 且選舉期間整個(gè) zk 集群都是不可用的，這就導(dǎo)致在選舉期間注冊(cè)服務(wù)癱瘓。

在云部署的環(huán)境下，因網(wǎng)絡(luò)問題使得 zk 集群失去 master 節(jié)點(diǎn)是較大概率會(huì)發(fā)生的事，雖然服務(wù)能夠最終恢復(fù)，但是漫長的選舉時(shí)間導(dǎo)致的注冊(cè)長期不可用是不能容忍的。

所以說，作為注冊(cè)中心，可用性的要求要高于一致性！

在 CAP 模型中，Zookeeper 整體遵循一致性（CP）原則，即在任何時(shí)候?qū)?Zookeeper 的訪問請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，但是當(dāng)機(jī)器下線或者宕機(jī)時(shí)，不能保證服務(wù)可用性。

那為什么 Zookeeper 不使用最終一致性（AP）模型呢？因?yàn)檫@個(gè)依賴 Zookeeper 的核心算法是 ZAB，所有設(shè)計(jì)都是為了強(qiáng)一致性。

這個(gè)對(duì)于分布式協(xié)調(diào)系統(tǒng)，完全沒沒有毛病，但是你如果將 Zookeeper 為分布式協(xié)調(diào)服務(wù)所做的一致性保障，用在注冊(cè)中心，或者說服務(wù)發(fā)現(xiàn)場景，這個(gè)其實(shí)就不合適。

nacos 與zk的選舉差異

Nacos 的行為：

選舉過程中的服務(wù)可用性：在 Nacos 集群中，如果 Leader 節(jié)點(diǎn)不可用，系統(tǒng)會(huì)觸發(fā) Leader 選舉。在選舉過程中，從節(jié)點(diǎn)（Follower）仍然可以繼續(xù)提供服務(wù)，例如：讀取服務(wù)和配置數(shù)據(jù)。

這是因?yàn)?Raft 協(xié)議允許從節(jié)點(diǎn)繼續(xù)提供 讀取操作，即使發(fā)生了網(wǎng)絡(luò)分區(qū)或 Leader 節(jié)點(diǎn)故障。在 Leader 選舉過程中，雖然寫操作（如服務(wù)注冊(cè)、配置更新等）會(huì)被暫時(shí)暫停，從節(jié)點(diǎn)依然能提供讀取操作，保證了系統(tǒng)的高可用性。

例如，在 Leader 失效時(shí)，集群會(huì)重新選舉新的 Leader，但從節(jié)點(diǎn)依然可以處理 讀請(qǐng)求，如查詢配置或服務(wù)列表等。這就是 AP 原則，允許系統(tǒng)繼續(xù)響應(yīng)請(qǐng)求，即使某些數(shù)據(jù)可能稍微滯后或不一致。

ZooKeeper 的行為：

選舉過程中的服務(wù)不可用性：在 ZooKeeper 中，Leader 節(jié)點(diǎn)不可用時(shí)，所有的寫操作會(huì)暫停，而且 從節(jié)點(diǎn)（Follower）無法提供服務(wù)。ZooKeeper 的設(shè)計(jì)目的是保證 一致性（C），因此它嚴(yán)格控制 數(shù)據(jù)一致性。

如果發(fā)生了 Leader 節(jié)點(diǎn)故障，ZooKeeper 集群會(huì)啟動(dòng) Leader 選舉，直到選舉出新的 Leader 節(jié)點(diǎn)后，系統(tǒng)才能恢復(fù)寫操作。

在選舉期間，從節(jié)點(diǎn)不能提供服務(wù)，即使是 讀取操作。這就意味著，如果發(fā)生網(wǎng)絡(luò)分區(qū)或 Leader 故障，ZooKeeper 集群會(huì)進(jìn)入一個(gè)短暫的 不可用狀態(tài)，直到選舉過程完成并確保一致性。

這種設(shè)計(jì)是 CP 原則 的體現(xiàn)，因?yàn)橄到y(tǒng)保證一致性（即所有操作在選舉前都不能執(zhí)行，直到一致性得到保障）而犧牲了可用性。

總結(jié)：

Nacos 在 Leader 選舉過程中，允許從節(jié)點(diǎn)繼續(xù)提供服務(wù)（主要是讀操作），即使在網(wǎng)絡(luò)分區(qū)或 Leader 故障時(shí)，保證了 系統(tǒng)可用性，這是 AP 原則
。
ZooKeeper 在 Leader 選舉過程中，不允許從節(jié)點(diǎn)提供服務(wù)，直到新 Leader 被選舉出來并且系統(tǒng)一致性得到保障，系統(tǒng)會(huì)在此期間進(jìn)入 不可用狀態(tài)，這是 CP 原則。

因此，Nacos 更加注重系統(tǒng)的 高可用性，即使在發(fā)生故障和網(wǎng)絡(luò)分區(qū)時(shí)也能保持服務(wù)的可用性；而 ZooKeeper 更加注重 一致性，即使會(huì)暫時(shí)不可用，但始終保證數(shù)據(jù)的一致性和正確性。