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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leader主要有三個(gè)功能： PING消息是指Learner的心跳信息;REQUEST消息是Follower發(fā)送的提議信息，包括寫請(qǐng)求及同步請(qǐng)求;ACK消息是 Follower的對(duì)提議的回復(fù)，超過半數(shù)的Follower通過，則commit該提議;REVALIDATE消息是用來延長SESSION有效時(shí)間。 Leader的工作流程簡圖如下所示，在實(shí)際實(shí)現(xiàn)中，流程要比下圖復(fù)雜得多，啟動(dòng)了三個(gè)線程來實(shí)現(xiàn)功能。 Follower主要有四個(gè)功能： Follower的消息循環(huán)處理如下幾種來自Leader的消息： Follower的工作流程簡圖如下所示，在實(shí)際實(shí)現(xiàn)中，F(xiàn)ollower是通過5個(gè)線程來實(shí)現(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. 這篇文章是本人對(duì)**上關(guān)于ZK的文章閱讀之后整理所得，作為入門級(jí)的了解。個(gè)人覺得看了上面的內(nèi)容就能基本了解Zookeeper的作用了，后面在結(jié)合實(shí)際項(xiàng)目使用加深自己的了解。

Consul和ZooKeeper的區(qū)別

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

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

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

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

Zookeeper原理解析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

zookeeper和eureka的區(qū)別

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

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

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

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

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

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

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

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

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

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

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