Zookpeer是什么？在系統(tǒng)中如何起作用？

Zookpeer是什么？在系統(tǒng)中如何起作用？

Zookeeper分布式服務(wù)框架是Apache Hadoop的一個子項目，它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題。如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項的管理等。

我們先看看它都提供了哪些功能，然后再看看使用它的這些功能能做點什么。

簡單的說，zookeeper=文件系統(tǒng)+通知機制。 Zookeeper維護一個類似文件系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)： 每個子目錄項如 NameService 都被稱作為 znode，和文件系統(tǒng)一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，**的不同在于znode是可以存儲數(shù)據(jù)的。 客戶端注冊監(jiān)聽它關(guān)心的目錄節(jié)點，當(dāng)目錄節(jié)點發(fā)生變化（數(shù)據(jù)改變、被刪除、子目錄節(jié)點增加刪除）時，zookeeper會通知客戶端。 這個似乎最簡單，在zookeeper的文件系統(tǒng)里創(chuàng)建一個目錄，即有**的path。

在我們使用tborg無法確定上游程序的部署機器時即可與下游程序約定好path，通過path即能互相探索發(fā)現(xiàn)，不見不散了。 程序總是需要配置的，如果程序分散部署在多臺機器上，要逐個改變配置就變得困難。 可以把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節(jié)點中，然后所有相關(guān)應(yīng)用程序?qū)@個目錄節(jié)點進行監(jiān)聽，一旦配置信息發(fā)生變化，每個應(yīng)用程序就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應(yīng)用到系統(tǒng)中就好。

集群管理無在乎兩點：是否有機器退出和加入、選舉master。 對于**點，所有機器約定在父目錄GroupMembers下創(chuàng)建臨時目錄節(jié)點，然后監(jiān)聽父目錄節(jié)點的子節(jié)點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創(chuàng)建的臨時目錄節(jié)點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它下船了。

當(dāng)然又會有新機器加入，也是類似：所有機器收到通知—新兄弟目錄加入，highcount又有了，有人上船了。 對于第二點，我們假設(shè)機器創(chuàng)建臨時順序編號目錄節(jié)點，每次選取編號最小的機器作為master就好。 有了zookeeper的一致性文件系統(tǒng)，鎖的問題變得容易。

鎖服務(wù)可以分為兩類，一個是保持獨占，另一個是控制時序。 對于**類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。廁所有言：來也沖沖，去也沖沖，用完刪除掉自己創(chuàng)建的distribute_lock 節(jié)點就釋放出鎖。

對于第二類， /distribute_lock 已經(jīng)預(yù)先存在，所有客戶端在它下面創(chuàng)建臨時順序編號目錄節(jié)點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。 兩種類型的隊列： 1、 同步隊列，當(dāng)一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。 2、隊列按照 FIFO 方式進行入隊和出隊操作。 **類，在約定目錄下創(chuàng)建臨時目錄節(jié)點，監(jiān)聽節(jié)點數(shù)目是否是我們要求的數(shù)目。

第二類，和分布式鎖服務(wù)中的控制時序場景基本原理一致，入列有編號，出列按編號。 Zookeeper中的角色主要有以下三類： 系統(tǒng)模型如圖所示： Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分 別是恢復(fù)模式（選主）和廣播模式（同步）。百科

當(dāng)服務(wù)啟動或者在***崩潰后，Zab就進入了恢復(fù)模式，當(dāng)***被選舉出來，且大多數(shù)Server完成了和 leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。 為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)。

所有的提議（proposal）都在被提出的時候加上 了zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個 新的epoch，標(biāo)識當(dāng)前屬于那個leader的統(tǒng)治時期。低32位用于遞增計數(shù)。

每個Server在工作過程中有三種狀態(tài)： 當(dāng)leader崩潰或者leader失去大多數(shù)的follower，這時候zk進入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個新的leader，讓所有的 Server都恢復(fù)到一個正確的狀態(tài)。Zk的選舉算法有兩種：一種是基于basic paxos實現(xiàn)的，另外一種是基于fast paxos算法實現(xiàn)的。系統(tǒng)默認的選舉算法為fast paxos。先介紹basic paxos流程： 通過流程分析我們可以得出：要使Leader獲得多數(shù)Server的支持，則Server總數(shù)必須是奇數(shù)2n+1，且存活的Server的數(shù)目不得少于n+1. 選完leader以后，zk就進入狀態(tài)同步過程。

Leader主要有三個功能： PING消息是指Learner的心跳信息;REQUEST消息是Follower發(fā)送的提議信息，包括寫請求及同步請求;ACK消息是 Follower的對提議的回復(fù)，超過半數(shù)的Follower通過，則commit該提議;REVALIDATE消息是用來延長SESSION有效時間。 Leader的工作流程簡圖如下所示，在實際實現(xiàn)中，流程要比下圖復(fù)雜得多，啟動了三個線程來實現(xiàn)功能。 Follower主要有四個功能： Follower的消息循環(huán)處理如下幾種來自Leader的消息： Follower的工作流程簡圖如下所示，在實際實現(xiàn)中，F(xiàn)ollower是通過5個線程來實現(xiàn)功能的。

https://blog.csdn.net/xinguan1267/article/details/38422149 https://blog.csdn.net/gs80140/article/details/51496925 https://www.2cto.com/kf/201708/668587.html https://blog.csdn.net/milhua/article/details/78931672 P.S. 這篇文章是本人對**上關(guān)于ZK的文章閱讀之后整理所得，作為入門級的了解。個人覺得看了上面的內(nèi)容就能基本了解Zookeeper的作用了，后面在結(jié)合實際項目使用加深自己的了解。

Consul和ZooKeeper的區(qū)別

Consul是一個在國外流行的服務(wù)發(fā)現(xiàn)和配置共享的服務(wù)軟件。本文翻譯自Consul的**文檔，文中重點講述：在與主流同類軟件ZooKeeper、Doozerd以及Etcd比較時，Consul的優(yōu)勢所在。

ZooKeeper、Doozerd、Etcd在架構(gòu)上都非常相似，它們都有服務(wù)節(jié)點（server node），而這些服務(wù)節(jié)點的操作都要求達到節(jié)點的仲裁數(shù)（通常，節(jié)點的仲裁數(shù)遵循的是簡單多數(shù)原則）。

此外，它們都是強一致性的，并且提供各種原語。通 過應(yīng)用程序內(nèi)部的客戶端lib庫，這些原語可以用來構(gòu)建復(fù)雜的分布式系統(tǒng)。Consul在一個單一的數(shù)據(jù)中心內(nèi)部使用服務(wù)節(jié)點。在每個數(shù)據(jù)中心中，為了Consule能夠運行，并且保持強一致性，Consul服務(wù)端需要仲裁。

然而，Consul原生支持多數(shù)據(jù)中心，就像一個豐富gossip系統(tǒng)連接服務(wù)器節(jié)點和客戶端一樣。當(dāng)提供K/V存儲的時候，這些系統(tǒng)具有大致相同的語義，讀取是強一致性的，并且在面對**分區(qū)的時候，為了保持一致性，讀取的可用性是可以犧牲的。然而，當(dāng)系統(tǒng)應(yīng)用于復(fù)雜情況時，這種差異會變得更加明顯。

Zookeeper原理解析

微信公眾號: Spark大數(shù)據(jù)一、Zookeeper介紹 ZooKeeper是一種為分布式應(yīng)用所設(shè)計的高可用、高性能且一致的開源協(xié)調(diào)服務(wù)，它提供了一項基本服務(wù)： 分布式鎖服務(wù) 。 分布式應(yīng)用可以基于它實現(xiàn)更高級的服務(wù)，實現(xiàn)諸如同步服務(wù)、配置維護和集群管理或者命名的服務(wù)。

Zookeeper服務(wù)自身組成一個集群，2n+1個（奇數(shù)）服務(wù)允許n個失效，集群內(nèi)一半以上機器可用，Zookeeper就可用。

假設(shè) 3臺機器組成的集群，可以有允許一臺失效，如果有2臺失效，這個集群就不可用，1<1.5，一般的搭建zookeeper集群時，以奇數(shù)臺機器來搭建。目的：是為了提高容錯能允許多損失一臺。 1.1 數(shù)據(jù)模型 1）ZooKeeper本質(zhì)上是一個 分布式的小文件存儲系統(tǒng) ; 2）Zookeeper表現(xiàn)為一個分層的文件系統(tǒng)目錄樹結(jié)構(gòu)（不同于文件系統(tǒng)的是，節(jié)點可以有自己的數(shù)據(jù)，而文件系統(tǒng)中的目錄節(jié)點只有子節(jié)點）， 每個節(jié)點可以存少量的數(shù)據(jù)（1M左右） 。 3）每個節(jié)點稱做一個ZNode。

每個ZNode都可以通過其路徑**標(biāo)識 。 4）ZooKeeper中的 每個節(jié)點存儲的數(shù)據(jù)要被原子性的操作 。也就是說讀操作將獲取與節(jié)點相關(guān)的所有數(shù)據(jù)，寫操作也將替換掉節(jié)點的所有數(shù)據(jù)。

5）在zookeeper創(chuàng)建順序節(jié)點（create -s ），節(jié)點路徑后加編號，這個計數(shù)對于此節(jié)點的父節(jié)點來說是**的。 /app/ /s1 /s2 6）ZooKeeper中的節(jié)點有兩種，分別為 臨時節(jié)點和**節(jié)點 。節(jié)點的類型在創(chuàng)建時即被確定，并且不能改變。

① 臨時節(jié)點 ：在客戶端用create -e創(chuàng)建，該節(jié)點的生命周期依賴于創(chuàng)建它們的會話。一旦會話(Session)結(jié)束，臨時節(jié)點將被自動刪除，當(dāng)然可以也可以手動刪除。雖然每個臨時的Znode都會綁定到一個客戶端會話，但他們對所有的客戶端還是可見的。

另外，**ZooKeeper的臨時節(jié)點不允許擁有子節(jié)點。 ② **節(jié)點 ：在客戶端用create 創(chuàng)建，該節(jié)點的生命周期不依賴于會話，并且只有在客戶端顯示執(zhí)行刪除操作的時候，他們才能被刪除。 7） 客戶端可以給節(jié)點設(shè)置watch，我們稱之為監(jiān)視器 。當(dāng)節(jié)點狀態(tài)發(fā)生改變時(Znode的增、刪、改)將會觸發(fā)watch所對應(yīng)的操作。

當(dāng)watch被觸發(fā)時，ZooKeeper將會向客戶端發(fā)送且僅發(fā)送一條通知。 分布式鎖 zookeeper 是高可用協(xié)調(diào)流程圖 1.2 zookeepr角色介紹 ***（leader） ，負責(zé)進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)（數(shù)據(jù)同步），發(fā)送心跳。 學(xué)習(xí)者（learner） ，包括跟隨者（follower）和觀察者（observer）。 跟隨者（follower） ，用于接受客戶端請求、向客戶端返回結(jié)果，在選主過程中參與投票。

觀察者（Observer） ，可以接受客戶端請求，會把請求轉(zhuǎn)發(fā)給leader， 但observer不參加投票過程，只同步leader的狀態(tài) ，observer的目的是為了擴展系統(tǒng)，提高讀取速度。 1）leader失效后會在follower中重新選舉新的leader 2）每個follower都和leader有連接，接受leader的數(shù)據(jù)更新操作 3）客戶端可以連接到每個server，每個server的數(shù)據(jù)完全相同 4）每個節(jié)點的服務(wù)Server，記錄事務(wù)日志和快照到持久存儲 1.3 工作原理 Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。 Zab協(xié)議有兩種模式 ，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。

恢復(fù)模式： 當(dāng)服務(wù)啟動或者在***崩潰后，Zab就進入了恢復(fù)模式，恢復(fù)模式不接受客戶端請求，當(dāng)***被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。 廣播模式： 一旦Leader已經(jīng)和多數(shù)的Follower進行了狀態(tài)同步后，他就可以開始廣播消息了，即進入廣播狀態(tài)。

這時候當(dāng)一個Server加入ZooKeeper服務(wù)中，它會在恢復(fù)模式下啟動，發(fā)現(xiàn)Leader，并和Leader進行狀態(tài)同步。待到同步結(jié)束，它也參與消息廣播。ZooKeeper的廣播狀態(tài)一直到Leader崩潰了或者Leader失去了大部分的Followers支持。

1.4 Zookeeper節(jié)點數(shù)據(jù)操作流程 (1）寫操作 1）在Client向Follwer 或 Observer 發(fā)出一個寫的請求; 2）Follwer 或 Observer 把請求發(fā)送給Leader; 3）Leader接收到以后向所有follower發(fā)起提案; 4）Follwer收到提案后執(zhí)行寫操作，然后把操作結(jié)果發(fā)送給Leader; 5）當(dāng)多數(shù)follower返回提案結(jié)果后，leader會commit該提議，通知其他Follower 和 Observer 同步信息; 6）Follwer 或Observer把請求結(jié)果返回給Client。 (2）讀操作 1）在Client向Follwer 或 Observer 發(fā)出一個讀的請求; 2）Follwer 或 Observer 把請求結(jié)果返回給Client; 1.5 主要特點 最終一致性 ：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的特性; 可靠性 ：具有簡單、健壯、良好的性能，如果消息被某一臺服務(wù)器接受，那么它將被所有的服務(wù)器接受; 實時性 ：Zookeeper保證客戶端將在一個時間間隔范圍內(nèi)獲得服務(wù)器的更新信息，或者服務(wù)器失效的信息。但由于**延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數(shù)據(jù)，如果需要**數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口; 等待無關(guān)(wait-free) ：慢的或者失效的client，不得干預(yù)快速的client的請求，使得每個client都能有效的等待; 原子性 ：更新只能成功或者失敗，沒有中間狀態(tài); 順序性 ：按照客戶端發(fā)送請求的順序更新數(shù)據(jù)。 1.6 zookeepr應(yīng)用場景 1.6.1 數(shù)據(jù)發(fā)布與訂閱 發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數(shù)據(jù)發(fā)布到ZK節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。

應(yīng)用配置集中到節(jié)點上，應(yīng)用啟動時主動獲取，并在節(jié)點上注冊一個watcher，每次配置更新都會通知到應(yīng)用。 1.6.2 命名空間服務(wù) 分布式命名服務(wù)，創(chuàng)建一個節(jié)點后，節(jié)點的路徑就是全局**的，可以作為全局名稱使用。 1.6.3 分布式通知/協(xié)調(diào) 不同的系統(tǒng)都監(jiān)聽同一個節(jié)點，一旦有了更新，另一個系統(tǒng)能夠收到通知。

1.6.4 分布式鎖 Zookeeper能保證數(shù)據(jù)的強一致性，用戶任何時候都可以相信集群中每個節(jié)點的數(shù)據(jù)都是相同的。鎖的兩種體現(xiàn)方式： (1）保持獨占 一個用戶創(chuàng)建一個節(jié)點作為鎖，另一個用戶檢測該節(jié)點，如果存在，代表別的用戶已經(jīng)鎖住，如果不存在，則可以創(chuàng)建一個節(jié)點，代表擁有一個鎖。 (2）控制時序 有一個節(jié)點作為父節(jié)點，其底下是帶有編號的子節(jié)點，所有要獲取鎖的用戶，需要在父節(jié)點下創(chuàng)建帶有編號的子節(jié)點，編號最小的會持有鎖;當(dāng)最我號的節(jié)點被刪除后，鎖被釋放，再重新找最我號的節(jié)點來持有鎖，這樣保證了全局有序。 1.6.5 集群管理 每個加入集群的機器都創(chuàng)建一個節(jié)點，寫入自己的狀態(tài)。

監(jiān)控父節(jié)點的用戶會收到通知，進行相應(yīng)的處理。離開時刪除節(jié)點，監(jiān)控父節(jié)點的用戶同樣會收到通知。

Zookeerper相關(guān)

Zookeeper是一種分布式協(xié)調(diào)服務(wù)。所謂分布式協(xié)調(diào)服務(wù)就是在分布式系統(tǒng)**享配置、協(xié)調(diào)鎖資源，提供命名服務(wù)。

Zookeeper的數(shù)據(jù)模型和數(shù)據(jù)結(jié)構(gòu)當(dāng)中的樹類似，很像文件系統(tǒng)的目錄。

Zookeeper的數(shù)據(jù)存儲也是基于節(jié)點，這種節(jié)點叫做Znode。Znode的引用方式是路徑引用，類似于文件路徑：/動物/人常見的API： create 創(chuàng)建節(jié)點 delete 刪除節(jié)點 exists 判斷節(jié)點是否存在 getData 獲取一個節(jié)點的數(shù)據(jù) getChildren 獲取節(jié)點下的所有節(jié)點 Zookeeper客戶端在請求讀操作的時候，可以選擇是否設(shè)置Watch。Watch理解成是注冊在特定Znode上的觸發(fā)器。當(dāng)這個Znode發(fā)生改變，即調(diào)用了create、delete、setData方法時，會觸發(fā)Znode上注冊的對應(yīng)事件，請求Watch的客戶端會接收到異步通知。

具體交互過程： 1、客戶端調(diào)用getData方法，watch參數(shù)是true。服務(wù)端接到請求，返回節(jié)點數(shù)據(jù)。并且在對應(yīng)的哈希表里插入被Watch的Znode路徑，以及Watcher數(shù)組。

2、當(dāng)被Watch的Znode已刪除，服務(wù)端會查找哈希表，根據(jù)key找到該Znode對應(yīng)的所有Watcher，異步通知客戶端，并且刪除哈希表中對應(yīng)的Key-Value。 為了防止單機故障，Zookeeper可以維護一個集群。Zookeeper Service集群時一主多從結(jié)構(gòu)。

更新數(shù)據(jù)時，先更新到主節(jié)點（節(jié)點指服務(wù)器，而不是Znode），再同步到從節(jié)點。 讀取數(shù)據(jù)時，直接讀取任意從節(jié)點。 為保證主從節(jié)點的數(shù)據(jù)一致性，Zookeeper采用了ZAB協(xié)議，這種協(xié)議非常類似于一致性算法Paxos和Raft。

ZAB即Zookeeper Atomic Broadcast，有效解決了Zookeeper集群崩潰恢復(fù)以及主從同步數(shù)據(jù)的問題。 Zab協(xié)議既不是強一致性，也不是弱一致性，而是處于兩者之間的單調(diào)一致性。它依靠事務(wù)ID和版本號，保證了數(shù)據(jù)的更新和讀取是有序的。 ZAB協(xié)議所的三種節(jié)點狀態(tài)： 1）Looking：選舉狀態(tài) 2）Following：Follower節(jié)點（從節(jié)點）所處的狀態(tài) 3）Leading：Leader節(jié)點（主節(jié)點）所處狀態(tài) 三種算法：leaderElection/AuthFastLeaderElection/FastLeaderElection1）Leader election 3）Discovery 4）Synchronization Zookeeper常規(guī)情況下更新數(shù)據(jù)的時候，由Leader廣播到所有Follower。

其過程如下： 1）客戶端發(fā)出寫入數(shù)據(jù)請求給任意Follower 2）Follower把寫入數(shù)據(jù)請求轉(zhuǎn)發(fā)給Leader 3）Leader采用二階段提交方式，先發(fā)送Propose廣播給Follower。 4）Follower接到Propose消息，寫入日志成功后，返回ACK消息給Leader 5）Leader接到半數(shù)以上ACK消息，返回成功給客戶端，并且廣播Commit請求給Follower。

zookeeper和eureka的區(qū)別

zookeeper和eureka的區(qū)別：
CAP 原則又稱 CAP 定理，1998年，加州大學(xué)的計算機科學(xué)家 Eric Brewer 提出的，指的是在一個分布式系統(tǒng)中，Consistency（一致性）、?Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可兼得（我們常說的魚和熊掌不可兼得）。CAP 原則也是 NoSQL 數(shù)據(jù)庫的基石。

1、一致性（Consistency，C）：
在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。

（等同于所有節(jié)點訪問同一份**的數(shù)據(jù)副本）。
2、可用性（Availability，A）：
在一個分布式系統(tǒng)的集群中一部分節(jié)點故障后，該集群是否還能夠正常響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）。
3、分區(qū)容錯性（Partition tolerance，P）：

大多數(shù)的分布式系統(tǒng)都分布在多個子**中，而每個子**就叫做一個區(qū)（partition）。

分區(qū)容錯的意思是，區(qū)間通信可能失敗。
比如阿里巴巴的服務(wù)器，一臺服務(wù)器放在上海，另一臺服務(wù)器放在北京，這就是兩個區(qū)，它們之間可能存在無法通信的情況。在一個分布式系統(tǒng)中一般分區(qū)容錯是無法避免的，因此可以認為 CAP 中的 P 總是成立的。

CAP 理論告訴我們，在 C 和 A 之間是無法同時做到。
zookeeper和eureka的區(qū)別：
Spring Cloud Eureka?-> AP
Spring Cloud Netflix 在設(shè)計 Eureka 時就緊遵AP原則。Eureka Server 也可以運行多個實例來構(gòu)建集群，解決單點問題，但不同于 ZooKeeper 的選舉 leader 的過程，Eureka Server 采用的是Peer to Peer 對等通信。

這是一種去中心化的架構(gòu)，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構(gòu)風(fēng)格中，節(jié)點通過彼此互相注冊來提高可用性，每個節(jié)點需要添加一個或多個有效的 serviceUrl 指向其他節(jié)點。每個節(jié)點都可被視為其他節(jié)點的副本。

在集群環(huán)境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節(jié)點上，當(dāng)宕機的服務(wù)器重新恢復(fù)后，Eureka 會再次將其納入到服務(wù)器集群管理之中。
當(dāng)節(jié)點開始接受客戶端請求時，所有的操作都會在節(jié)點間進行**操作，將請求**到該 Eureka Server 當(dāng)前所知的其它所有節(jié)點中。

當(dāng)一個新的 Eureka Server 節(jié)點啟動后，會首先嘗試從鄰近節(jié)點獲取所有注冊列表信息，并完成初始化。Eureka Server 通過 getEurekaServiceUrls方法獲取所有的節(jié)點，并且會通過心跳契約的方式定期更新。

默認情況下，如果 Eureka Server 在一定時間內(nèi)沒有接收到某個服務(wù)實例的心跳，Eureka Server 將會注銷該實例。當(dāng) Eureka Server 節(jié)點在短時間內(nèi)丟失過多的心跳時，那么這個節(jié)點就會進入自我保護模式。
Apache Zookeeper -> CP
與 Eureka 有所不同，Apache Zookeeper 在設(shè)計時就緊遵CP原則，即任何時候?qū)ookeeper 的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時系統(tǒng)對**分割具備容錯性，但是 Zookeeper 不能保證每次服務(wù)請求都是可達的。
從 Zookeeper 的實際應(yīng)用情況來看，在使用 Zookeeper 獲取服務(wù)列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數(shù)以上服務(wù)器節(jié)點不可用，那么將無法處理該請求。

所以說，Zookeeper 不能保證服務(wù)可用性。
當(dāng)然，在大多數(shù)分布式環(huán)境中，尤其是涉及到數(shù)據(jù)存儲的場景，數(shù)據(jù)一致性應(yīng)該是首先被保證的，這也是 Zookeeper 設(shè)計緊遵CP原則的另一個原因。
但是對于服務(wù)發(fā)現(xiàn)來說，情況就不太一樣了，針對同一個服務(wù)，即使注冊中心的不同節(jié)點保存的服務(wù)提供者信息不盡相同，也并不會造成災(zāi)難性的后果。