如果有人問(wèn)你 ZooKeeper 是什么，就把這篇文章發(fā)給他

前言

提到ZooKeeper，相信大家都不會(huì)陌生。Dubbo，Kafka,Hadoop等等項(xiàng)目里都能看到它的影子。但是你真的了解 ZooKeeper 嗎？如果面試官讓你給他講講 ZooKeeper 是個(gè)什么東西，你能回答到什么地步呢？

我會(huì)用兩個(gè)篇幅介紹ZooKeeper ，第一篇是概念性的認(rèn)識(shí)，這篇你會(huì)得到 ZooKeeper 是什么，ZooKeeper 設(shè)計(jì)的目標(biāo)，ZooKeeper 能做什么和ZooKeeper 基本的概念。第二篇我會(huì)從實(shí)戰(zhàn)出發(fā)，安裝ZooKeeper，寫(xiě)一些ZooKeeper 具體應(yīng)用場(chǎng)景的代碼實(shí)現(xiàn)。

一、ZooKeeper是什么

ZooKeeper 是一個(gè)分布式的，開(kāi)放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個(gè)開(kāi)源的實(shí)現(xiàn)，是Hadoop和Hbase的重要組件。它是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、域名服務(wù)、分布式同步、組服務(wù)等。

官網(wǎng)：http://zookeeper.apache.org/

源碼：https://github.com/apache/zookeeper

二、ZooKeeper 的由來(lái)

下面這段內(nèi)容摘自《從Paxos到Zookeeper 》 ，本文中很多的名詞介紹也來(lái)自本書(shū)。

Zookeeper 最早起源于雅虎研究院的一個(gè)研究小組。在當(dāng)時(shí)，研究人員發(fā)現(xiàn)，在雅虎內(nèi)部很多大型系統(tǒng)基本都需要依賴(lài)一個(gè)類(lèi)似的系統(tǒng)來(lái)進(jìn)行分布式協(xié)調(diào)，但是這些系統(tǒng)往往都存在分布式單點(diǎn)問(wèn)題。所以，雅虎的開(kāi)發(fā)人員就試圖開(kāi)發(fā)一個(gè)通用的無(wú)單點(diǎn)問(wèn)題的分布式協(xié)調(diào)框架，以便讓開(kāi)發(fā)人員將精力集中在處理業(yè)務(wù)邏輯上。
關(guān)于“ZooKeeper”這個(gè)項(xiàng)目的名字，其實(shí)也有一段趣聞。在立項(xiàng)初期，考慮到之前內(nèi)部很多項(xiàng)目都是使用動(dòng)物的名字來(lái)命名的（例如著名的Pig項(xiàng)目),雅虎的工程師希望給這個(gè)項(xiàng)目也取一個(gè)動(dòng)物的名字。時(shí)任研究院的首席科學(xué)家 RaghuRamakrishnan 開(kāi)玩笑地說(shuō)：“在這樣下去，我們這兒就變成動(dòng)物園了！”此話一出，大家紛紛表示就叫動(dòng)物園管理員吧一一一因?yàn)楦鱾€(gè)以動(dòng)物命名的分布式組件放在一起，雅虎的整個(gè)分布式系統(tǒng)看上去就像一個(gè)大型的動(dòng)物園了，而 Zookeeper 正好要用來(lái)進(jìn)行分布式環(huán)境的協(xié)調(diào)一一于是，Zookeeper 的名字也就由此誕生了。

三、ZooKeeper的特性

• 順序一致性，從同一個(gè)客戶端發(fā)起的事務(wù)請(qǐng)求，最終將會(huì)嚴(yán)格地按照其發(fā)起順序被應(yīng)用到Zookeeper中去。

• 原子性，所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的，即整個(gè)集群要么都成功應(yīng)用了某個(gè)事務(wù)，要么都沒(méi)有應(yīng)用。

• 單一視圖，無(wú)論客戶端連接的是哪個(gè) Zookeeper 服務(wù)器，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。

• 可靠性，一旦服務(wù)端成功地應(yīng)用了一個(gè)事務(wù)，并完成對(duì)客戶端的響應(yīng)，那么該事務(wù)所引起的服務(wù)端狀態(tài)變更將會(huì)一直被保留，除非有另一個(gè)事務(wù)對(duì)其進(jìn)行了變更。

• 實(shí)時(shí)性，Zookeeper 保證在一定的時(shí)間段內(nèi)，客戶端最終一定能夠從服務(wù)端上讀取到最新的數(shù)據(jù)狀態(tài)。

四、ZooKeeper的設(shè)計(jì)目標(biāo)

• 簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)
  Zookeeper 使得分布式程序能夠通過(guò)一個(gè)共享的樹(shù)形結(jié)構(gòu)的名字空間來(lái)進(jìn)行相互協(xié)調(diào)，即Zookeeper 服務(wù)器內(nèi)存中的數(shù)據(jù)模型由一系列被稱(chēng)為ZNode的數(shù)據(jù)節(jié)點(diǎn)組成，Zookeeper 將全量的數(shù)據(jù)存儲(chǔ)在內(nèi)存中，以此來(lái)提高服務(wù)器吞吐、減少延遲的目的。

• 可以構(gòu)建集群
  Zookeeper 集群通常由一組機(jī)器構(gòu)成，組成 Zookeeper 集群的而每臺(tái)機(jī)器都會(huì)在內(nèi)存中維護(hù)當(dāng)前服務(wù)器狀態(tài)，并且每臺(tái)機(jī)器之間都相互通信。

• 順序訪問(wèn)
  對(duì)于來(lái)自客戶端的每個(gè)更新請(qǐng)求，Zookeeper 都會(huì)分配一個(gè)全局唯一的遞增編號(hào)，這個(gè)編號(hào)反映了所有事務(wù)操作的先后順序。

• 高性能
  Zookeeper 和Redis一樣全量數(shù)據(jù)存儲(chǔ)在內(nèi)存中，100%讀請(qǐng)求壓測(cè)QPS 12-13W。

五、關(guān)于 ZooKeeper 的一些重要概念

5.1 Zookeeper 集群：

Zookeeper 是一個(gè)由多個(gè) server 組成的集群,一個(gè) leader，多個(gè) follower。（這個(gè)不同于我們常見(jiàn)的Master/Slave模式）leader 為客戶端服務(wù)器提供讀寫(xiě)服務(wù)，除了leader外其他的機(jī)器只能提供讀服務(wù)。
每個(gè) server 保存一份數(shù)據(jù)副本全數(shù)據(jù)一致，分布式讀 follower，寫(xiě)由 leader 實(shí)施更新請(qǐng)求轉(zhuǎn)發(fā)，由 leader 實(shí)施更新請(qǐng)求順序進(jìn)行，來(lái)自同一個(gè) client 的更新請(qǐng)求按其發(fā)送順序依次執(zhí)行數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失敗。全局唯一數(shù)據(jù)視圖，client 無(wú)論連接到哪個(gè) server，數(shù)據(jù)視圖都是一致的實(shí)時(shí)性，在一定事件范圍內(nèi)，client 能讀到最新數(shù)據(jù)。

5.2 集群角色

Leader：是整個(gè) Zookeeper 集群工作機(jī)制中的核心 。Leader 作為整個(gè) ZooKeeper 集群的主節(jié)點(diǎn)，負(fù)責(zé)響應(yīng)所有對(duì) ZooKeeper 狀態(tài)變更的請(qǐng)求。
主要工作：

• 事務(wù)請(qǐng)求的唯一調(diào)度和處理，保障集群處理事務(wù)的順序性。
• 集群內(nèi)各服務(wù)器的調(diào)度者。

Leader 選舉是 Zookeeper 最重要的技術(shù)之一，也是保障分布式數(shù)據(jù)一致性的關(guān)鍵所在。我們以三臺(tái)機(jī)器為例，在服務(wù)器集群初始化階段，當(dāng)有一臺(tái)服務(wù)器Server1啟動(dòng)時(shí)候是無(wú)法完成選舉的，當(dāng)?shù)诙_(tái)機(jī)器 Server2 啟動(dòng)后兩臺(tái)機(jī)器能互相通信，每臺(tái)機(jī)器都試圖找到一個(gè)leader，于是便進(jìn)入了 leader 選舉流程.

1. 每個(gè) server 發(fā)出一個(gè)投票
   投票的最基本元素是（SID-服務(wù)器id,ZXID-事物id）
2. 接受來(lái)自各個(gè)服務(wù)器的投票
3. 處理投票
   優(yōu)先檢查 ZXID(數(shù)據(jù)越新ZXID越大),ZXID比較大的作為leader，ZXID一樣的情況下比較SID
4. 統(tǒng)計(jì)投票
   這里有個(gè)過(guò)半的概念，大于集群機(jī)器數(shù)量的一半，即大于或等于（n/2+1）,我們這里的由三臺(tái)，大于等于2即為達(dá)到“過(guò)半”的要求。
   這里也有引申到為什么 Zookeeper 集群推薦是單數(shù)。

通過(guò)以上可以發(fā)現(xiàn)，3臺(tái)服務(wù)器和4臺(tái)服務(wù)器都最多允許1臺(tái)服務(wù)器掛掉，5臺(tái)服務(wù)器和6臺(tái)服務(wù)器都最多允許2臺(tái)服務(wù)器掛掉,明顯4臺(tái)服務(wù)器成本高于3臺(tái)服務(wù)器成本，6臺(tái)服務(wù)器成本高于5服務(wù)器成本。這是由于半數(shù)以上投票通過(guò)決定的。

1. 改變服務(wù)器狀態(tài)
   一旦確定了 leader，服務(wù)器就會(huì)更改自己的狀態(tài)，且一半不會(huì)再發(fā)生變化，比如新機(jī)器加入集群、非 leader 掛掉一臺(tái)。

Follower?：是 Zookeeper 集群狀態(tài)的跟隨者。他的邏輯就比較簡(jiǎn)單。除了響應(yīng)本服務(wù)器上的讀請(qǐng)求外，follower 還要處理leader 的提議，并在 leader 提交該提議時(shí)在本地也進(jìn)行提交。另外需要注意的是，leader 和 follower 構(gòu)成ZooKeeper 集群的法定人數(shù)，也就是說(shuō)，只有他們才參與新 leader的選舉、響應(yīng) leader 的提議。

Observer?：服務(wù)器充當(dāng)一個(gè)觀察者的角色。如果 ZooKeeper 集群的讀取負(fù)載很高，或者客戶端多到跨機(jī)房，可以設(shè)置一些 observer 服務(wù)器，以提高讀取的吞吐量。Observer 和 Follower 比較相似，只有一些小區(qū)別：首先 observer 不屬于法定人數(shù)，即不參加選舉也不響應(yīng)提議，也不參與寫(xiě)操作的“過(guò)半寫(xiě)成功”策略；其次是 observer 不需要將事務(wù)持久化到磁盤(pán)，一旦 observer 被重啟，需要從 leader 重新同步整個(gè)名字空間。

5.3會(huì)話（Session）

Session 指的是 ZooKeeper 服務(wù)器與客戶端會(huì)話。在 ZooKeeper 中，一個(gè)客戶端連接是指客戶端和服務(wù)器之間的一個(gè) TCP 長(zhǎng)連接。客戶端啟動(dòng)的時(shí)候，首先會(huì)與服務(wù)器建立一個(gè) TCP 連接，從第一次連接建立開(kāi)始，客戶端會(huì)話的生命周期也開(kāi)始了。通過(guò)這個(gè)連接，客戶端能夠通過(guò)心跳檢測(cè)與服務(wù)器保持有效的會(huì)話，也能夠向Zookeeper 服務(wù)器發(fā)送請(qǐng)求并接受響應(yīng)，同時(shí)還能夠通過(guò)該連接接收來(lái)自服務(wù)器的Watch事件通知。 Session 的 sessionTimeout 值用來(lái)設(shè)置一個(gè)客戶端會(huì)話的超時(shí)時(shí)間。當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或是客戶端主動(dòng)斷開(kāi)連接等各種原因?qū)е驴蛻舳诉B接斷開(kāi)時(shí)，只要在sessionTimeout規(guī)定的時(shí)間內(nèi)能夠重新連接上集群中任意一臺(tái)服務(wù)器，那么之前創(chuàng)建的會(huì)話仍然有效。在為客戶端創(chuàng)建會(huì)話之前，服務(wù)端首先會(huì)為每個(gè)客戶端都分配一個(gè)sessionID。由于 sessionID 是 Zookeeper 會(huì)話的一個(gè)重要標(biāo)識(shí)，許多與會(huì)話相關(guān)的運(yùn)行機(jī)制都是基于這個(gè) sessionID 的，因此，無(wú)論是哪臺(tái)服務(wù)器為客戶端分配的 sessionID，都務(wù)必保證全局唯一。

5.3.1 會(huì)話（Session）

在Zookeeper客戶端與服務(wù)端成功完成連接創(chuàng)建后，就創(chuàng)建了一個(gè)會(huì)話，Zookeeper會(huì)話在整個(gè)運(yùn)行期間的生命周期中，會(huì)在不同的會(huì)話狀態(tài)中之間進(jìn)行切換，這些狀態(tài)可以分為CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。

一旦客戶端開(kāi)始創(chuàng)建Zookeeper對(duì)象，那么客戶端狀態(tài)就會(huì)變成CONNECTING狀態(tài)，同時(shí)客戶端開(kāi)始嘗試連接服務(wù)端，連接成功后，客戶端狀態(tài)變?yōu)镃ONNECTED，通常情況下，由于斷網(wǎng)或其他原因，客戶端與服務(wù)端之間會(huì)出現(xiàn)斷開(kāi)情況，一旦碰到這種情況，Zookeeper客戶端會(huì)自動(dòng)進(jìn)行重連服務(wù)，同時(shí)客戶端狀態(tài)再次變成CONNCTING，直到重新連上服務(wù)端后，狀態(tài)又變?yōu)镃ONNECTED，在通常情況下，客戶端的狀態(tài)總是介于CONNECTING 和CONNECTED 之間。但是，如果出現(xiàn)諸如會(huì)話超時(shí)、權(quán)限檢查或是客戶端主動(dòng)退出程序等情況，客戶端的狀態(tài)就會(huì)直接變更為CLOSE狀態(tài)。

5.3.2 會(huì)話創(chuàng)建

Session是Zookeeper中的會(huì)話實(shí)體，代表了一個(gè)客戶端會(huì)話，其包含了如下四個(gè)屬性

1. sessionID。會(huì)話ID，唯一標(biāo)識(shí)一個(gè)會(huì)話，每次客戶端創(chuàng)建新的會(huì)話時(shí)，Zookeeper都會(huì)為其分配一個(gè)全局唯一的sessionID。
2. TimeOut。會(huì)話超時(shí)時(shí)間，客戶端在構(gòu)造Zookeeper實(shí)例時(shí)，會(huì)配置sessionTimeout參數(shù)用于指定會(huì)話的超時(shí)時(shí)間，Zookeeper客戶端向服務(wù)端發(fā)送這個(gè)超時(shí)時(shí)間后，服務(wù)端會(huì)根據(jù)自己的超時(shí)時(shí)間限制最終確定會(huì)話的超時(shí)時(shí)間。
3. TickTime。下次會(huì)話超時(shí)時(shí)間點(diǎn)，為了便于Zookeeper對(duì)會(huì)話實(shí)行”分桶策略”管理，同時(shí)為了高效低耗地實(shí)現(xiàn)會(huì)話的超時(shí)檢查與清理，Zookeeper會(huì)為每個(gè)會(huì)話標(biāo)記一個(gè)下次會(huì)話超時(shí)時(shí)間點(diǎn)，其值大致等于當(dāng)前時(shí)間加上TimeOut。
4. isClosing。標(biāo)記一個(gè)會(huì)話是否已經(jīng)被關(guān)閉，當(dāng)服務(wù)端檢測(cè)到會(huì)話已經(jīng)超時(shí)失效時(shí)，會(huì)將該會(huì)話的isClosing標(biāo)記為”已關(guān)閉”，這樣就能確保不再處理來(lái)自該會(huì)話的心情求了。

Zookeeper為了保證請(qǐng)求會(huì)話的全局唯一性，在SessionTracker初始化時(shí)，調(diào)用initializeNextSession方法生成一個(gè)sessionID，之后在Zookeeper運(yùn)行過(guò)程中，會(huì)在該sessionID的基礎(chǔ)上為每個(gè)會(huì)話進(jìn)行分配，初始化算法如下

```
	public static long initializeNextSession(long id) {
	  long nextSid = 0;
	  // 無(wú)符號(hào)右移8位使為了避免左移24后，再右移8位出現(xiàn)負(fù)數(shù)而無(wú)法通過(guò)高8位確定sid值
	  nextSid = (System.currentTimeMillis() << 24) >>> 8;
	  nextSid = nextSid | (id << 56);
	  return nextSid;
	}

	```

5.3.3 會(huì)話管理

Zookeeper的會(huì)話管理主要是通過(guò)SessionTracker來(lái)負(fù)責(zé)，其采用了分桶策略（將類(lèi)似的會(huì)話放在同一區(qū)塊中進(jìn)行管理）進(jìn)行管理，以便Zookeeper對(duì)會(huì)話進(jìn)行不同區(qū)塊的隔離處理以及同一區(qū)塊的統(tǒng)一處理。

5.4 數(shù)據(jù)節(jié)點(diǎn) Znode

在Zookeeper中，“節(jié)點(diǎn)"分為兩類(lèi)，第一類(lèi)同樣是指構(gòu)成集群的機(jī)器，我們稱(chēng)之為機(jī)器節(jié)點(diǎn)；第二類(lèi)則是指數(shù)據(jù)模型中的數(shù)據(jù)單元，我們稱(chēng)之為數(shù)據(jù)節(jié)點(diǎn)一一ZNode。
Zookeeper將所有數(shù)據(jù)存儲(chǔ)在內(nèi)存中，數(shù)據(jù)模型是一棵樹(shù)（Znode Tree)，由斜杠（/）的進(jìn)行分割的路徑，就是一個(gè)Znode，例如/foo/path1。每個(gè)上都會(huì)保存自己的數(shù)據(jù)內(nèi)容，同時(shí)還會(huì)保存一系列屬性信息。

5.4.1 節(jié)點(diǎn)類(lèi)型

在Zookeeper中，node可以分為持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)和順序節(jié)點(diǎn)三大類(lèi)。
可以通過(guò)組合生成如下四種類(lèi)型節(jié)點(diǎn)??
1. PERSISTENT
持久節(jié)點(diǎn),節(jié)點(diǎn)創(chuàng)建后便一直存在于Zookeeper服務(wù)器上，直到有刪除操作來(lái)主動(dòng)清楚該節(jié)點(diǎn)。
2. PERSISTENT_SEQUENTIAL
持久順序節(jié)點(diǎn),相比持久節(jié)點(diǎn)，其新增了順序特性，每個(gè)父節(jié)點(diǎn)都會(huì)為它的第一級(jí)子節(jié)點(diǎn)維護(hù)一份順序，用于記錄每個(gè)子節(jié)點(diǎn)創(chuàng)建的先后順序。在創(chuàng)建節(jié)點(diǎn)時(shí)，會(huì)自動(dòng)添加一個(gè)數(shù)字后綴，作為新的節(jié)點(diǎn)名，該數(shù)字后綴的上限是整形的最大值。
3.EPEMERAL
臨時(shí)節(jié)點(diǎn)，臨時(shí)節(jié)點(diǎn)的生命周期與客戶端會(huì)話綁定，客戶端失效，節(jié)點(diǎn)會(huì)被自動(dòng)清理。同時(shí)，Zookeeper規(guī)定不能基于臨時(shí)節(jié)點(diǎn)來(lái)創(chuàng)建子節(jié)點(diǎn)，即臨時(shí)節(jié)點(diǎn)只能作為葉子節(jié)點(diǎn)。
4.EPEMERAL_SEQUENTIAL
臨時(shí)順序節(jié)點(diǎn),在臨時(shí)節(jié)點(diǎn)的基礎(chǔ)添加了順序特性。

5.5 版本——保證分布式數(shù)據(jù)原子性操作

每個(gè)數(shù)據(jù)節(jié)點(diǎn)都具有三種類(lèi)型的版本信息，對(duì)數(shù)據(jù)節(jié)點(diǎn)的任何更新操作都會(huì)引起版本號(hào)的變化。

version– 當(dāng)前數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)內(nèi)容的版本號(hào)
cversion– 當(dāng)前數(shù)據(jù)子節(jié)點(diǎn)的版本號(hào)
aversion– 當(dāng)前數(shù)據(jù)節(jié)點(diǎn)ACL變更版本號(hào)

上述各版本號(hào)都是表示修改次數(shù)，如version為1表示對(duì)數(shù)據(jù)節(jié)點(diǎn)的內(nèi)容變更了一次。即使前后兩次變更并沒(méi)有改變數(shù)據(jù)內(nèi)容，version的值仍然會(huì)改變。version可以用于寫(xiě)入驗(yàn)證，類(lèi)似于CAS。

5.6watcher事件監(jiān)聽(tīng)器

ZooKeeper允許用戶在指定節(jié)點(diǎn)上注冊(cè)一些Watcher，當(dāng)數(shù)據(jù)節(jié)點(diǎn)發(fā)生變化的時(shí)候，ZooKeeper服務(wù)器會(huì)把這個(gè)變化的通知發(fā)送給感興趣的客戶端

5.7 ACL 權(quán)限控制——保障數(shù)據(jù)的安全

ACL是Access Control Lists 的簡(jiǎn)寫(xiě)， ZooKeeper采用ACL策略來(lái)進(jìn)行權(quán)限控制，有以下權(quán)限：
CREATE:創(chuàng)建子節(jié)點(diǎn)的權(quán)限
READ:獲取節(jié)點(diǎn)數(shù)據(jù)和子節(jié)點(diǎn)列表的權(quán)限
WRITE:更新節(jié)點(diǎn)數(shù)據(jù)的權(quán)限
DELETE:刪除子節(jié)點(diǎn)的權(quán)限
ADMIN:設(shè)置節(jié)點(diǎn)ACL的權(quán)限

5.8 Paxos算法

Paxos算法是基于消息傳遞且具有高度容錯(cuò)特性的一致性算法，是目前公認(rèn)的解決分布式一致性問(wèn)題最有效的算法之一。（其他算法有二階段提交、三階段提交等）
篇幅較長(zhǎng) 可以參考https://www.cnblogs.com/linbingdong/p/6253479.html

六、ZooKeeper 可以做什么？

• 分布式服務(wù)注冊(cè)與訂閱

  在分布式環(huán)境中，為了保證高可用性，通常同一個(gè)應(yīng)用或同一個(gè)服務(wù)的提供方都會(huì)部署多份，達(dá)到對(duì)等服務(wù)。而消費(fèi)者就須要在這些對(duì)等的服務(wù)器中選擇一個(gè)來(lái)執(zhí)行相關(guān)的業(yè)務(wù)邏輯，比較典型的服務(wù)注冊(cè)與訂閱，代表：dubbo。
  

• 分布式配置中心
  發(fā)布與訂閱模型，即所謂的配置中心，顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到ZK節(jié)點(diǎn)上，供訂閱者獲取數(shù)據(jù)，實(shí)現(xiàn)配置信息的集中式管理和動(dòng)態(tài)更新。代表：百度的disconf。
  github：https://github.com/knightliao/disconf

• 命名服務(wù)
  在分布式系統(tǒng)中，通過(guò)使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來(lái)獲取資源或服務(wù)的地址，提供者等信息。被命名的實(shí)體通常可以是集群中的機(jī)器，提供的服務(wù)地址，進(jìn)程對(duì)象等等——這些我們都可以統(tǒng)稱(chēng)他們?yōu)槊郑∟ame）。其中較為常見(jiàn)的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過(guò)調(diào)用ZK提供的創(chuàng)建節(jié)點(diǎn)的API，能夠很容易創(chuàng)建一個(gè)全局唯一的path，這個(gè)path就可以作為一個(gè)名稱(chēng)。
  

• 分布式鎖
  分布式鎖，這個(gè)主要得益于ZooKeeper為我們保證了數(shù)據(jù)的強(qiáng)一致性。鎖服務(wù)可以分為兩類(lèi)，一個(gè)是保持獨(dú)占，另一個(gè)是控制時(shí)序。
  所謂保持獨(dú)占，就是所有試圖來(lái)獲取這個(gè)鎖的客戶端，最終只有一個(gè)可以成功獲得這把鎖。通常的做法是把zk上的一個(gè)znode看作是一把鎖，通過(guò)create znode的方式來(lái)實(shí)現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn)，最終成功創(chuàng)建的那個(gè)客戶端也即擁有了這把鎖。
  控制時(shí)序，就是所有視圖來(lái)獲取這個(gè)鎖的客戶端，最終都是會(huì)被安排執(zhí)行，只是有個(gè)全局時(shí)序了。做法和上面基本類(lèi)似，只是這里 /distribute_lock 已絆預(yù)先存在，客戶端在它下面創(chuàng)建臨時(shí)有序節(jié)點(diǎn)（這個(gè)可以通過(guò)節(jié)點(diǎn)的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來(lái)指定）。Zk的父節(jié)點(diǎn)（/distribute_lock）維持一份sequence,保證子節(jié)點(diǎn)創(chuàng)建的時(shí)序性，從而也形成了每個(gè)客戶端的全局時(shí)序

• Master選舉

• 負(fù)載均衡
  

參考

• 《從Paxos到Zookeeper 》
• 《ZooKeeper深入淺出 》

作者：codeyuyu

鏈接：http://www.imooc.com/article/251135#

來(lái)源：慕課網(wǎng)