什么是?Zookeeper

Zookeeper 分布式服務(wù)框架是Apache Hadoop 的一個(gè)子項(xiàng)目，它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，如：

統(tǒng)一命名服務(wù)

狀態(tài)同步服務(wù)

集群管理

分布式應(yīng)用配置項(xiàng)的管理等

Zookeeper已經(jīng)成為Hadoop生態(tài)系統(tǒng)中的基礎(chǔ)組件。

Zookeeper的基本原理和架構(gòu)

1、Zookeeper的角色

??領(lǐng)導(dǎo)者（leader）：負(fù)責(zé)進(jìn)行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)。

??學(xué)習(xí)者（learner）：包括跟隨者（follower）和觀察者（observer），follower用于接受客戶端請(qǐng)求并想客戶端返回結(jié)果，在選主過程中參與投票。

??Observer：可以接受客戶端連接，將寫請(qǐng)求轉(zhuǎn)發(fā)給leader，但observer不參加投票過程，只同步leader的狀態(tài)，observer的目的是為了擴(kuò)展系統(tǒng)，提高讀取速度

??客戶端（client）：請(qǐng)求發(fā)起方

? Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)Server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議。

Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(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)：

LOOKING：當(dāng)前Server不知道leader是誰，正在搜尋

LEADING：當(dāng)前Server即為選舉出來的leader

FOLLOWING：leader已經(jīng)選舉出來，當(dāng)前Server與之同步

其他文檔：http://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html

2、Zookeeper 的讀寫機(jī)制

? Zookeeper是一個(gè)由多個(gè)server組成的集群

? 一個(gè)leader，多個(gè)follower

? 每個(gè)server保存一份數(shù)據(jù)副本

? 全局?jǐn)?shù)據(jù)一致

? 分布式讀寫

? 更新請(qǐng)求轉(zhuǎn)發(fā)，由leader實(shí)施

3、Zookeeper 的保證

? 更新請(qǐng)求順序進(jìn)行，來自同一個(gè)client的更新請(qǐng)求按其發(fā)送順序依次執(zhí)行

? 數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失敗

? 全局唯一數(shù)據(jù)視圖，client無論連接到哪個(gè)server，數(shù)據(jù)視圖都是一致的

? 實(shí)時(shí)性，在一定事件范圍內(nèi)，client能讀到最新數(shù)據(jù)

4、Zookeeper節(jié)點(diǎn)數(shù)據(jù)操作流程

1.在Client向Follwer發(fā)出一個(gè)寫的請(qǐng)求

2.Follwer把請(qǐng)求發(fā)送給Leader

3.Leader接收到以后開始發(fā)起投票并通知Follwer進(jìn)行投票

4.Follwer把投票結(jié)果發(fā)送給Leader

5.Leader將結(jié)果匯總后如果需要寫入，則開始寫入同時(shí)把寫入操作通知給Leader，然后commit;

6.Follwer把請(qǐng)求結(jié)果返回給Client

?

5、Zookeeper工作原理

??Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議。

Zab協(xié)議有兩種模式，它們分別是：恢復(fù)模式和廣播模式。

當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來，且大多數(shù)server的完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。

6、數(shù)據(jù)一致性與paxos 算法

? 據(jù)說Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持?jǐn)?shù)據(jù)的一致性，這里有個(gè)原則就是：

? 在一個(gè)分布式數(shù)據(jù)庫系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)都執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。

? Paxos算法解決的什么問題呢，解決的就是保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的操作序列。好吧，這還不簡單，master維護(hù)一個(gè)全局寫隊(duì)列，所有寫操作都必須 放入這個(gè)隊(duì)列編號(hào)，那么無論我們寫多少個(gè)節(jié)點(diǎn)，只要寫操作是按編號(hào)來的，就能保證一致性。沒錯(cuò)，就是這樣，可是如果master掛了呢。

? Paxos算法通過投票來對(duì)寫操作進(jìn)行全局編號(hào)，同一時(shí)刻，只有一個(gè)寫操作被批準(zhǔn)，同時(shí)并發(fā)的寫操作要去爭取選票，

只有獲得過半數(shù)選票的寫操作才會(huì)被 批準(zhǔn)（所以永遠(yuǎn)只會(huì)有一個(gè)寫操作得到批準(zhǔn)），其他的寫操作競爭失敗只好再發(fā)起一

輪投票，就這樣，在日復(fù)一日年復(fù)一年的投票中，所有寫操作都被嚴(yán)格編號(hào)排 序。編號(hào)嚴(yán)格遞增，當(dāng)一個(gè)節(jié)點(diǎn)接受了一個(gè)

編號(hào)為100的寫操作，之后又接受到編號(hào)為99的寫操作（因?yàn)榫W(wǎng)絡(luò)延遲等很多不可預(yù)見原因），它馬上能意識(shí)到自己 數(shù)據(jù)

不一致了，自動(dòng)停止對(duì)外服務(wù)并重啟同步過程。任何一個(gè)節(jié)點(diǎn)掛掉都不會(huì)影響整個(gè)集群的數(shù)據(jù)一致性（總2n+1臺(tái)，除非掛掉大于n臺(tái)）。

總結(jié)

? Zookeeper 作為 Hadoop 項(xiàng)目中的一個(gè)子項(xiàng)目，是 Hadoop 集群管理的一個(gè)必不可少的模塊，它主要用來控制集群中的數(shù)據(jù)，

如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態(tài)同步等。

關(guān)于Paxos算法可以查看文章 Zookeeper全解析——Paxos作為靈魂

推薦書籍：《從Paxos到Zookeeper分布式一致性原理與實(shí)踐》

7、Observer

? Zookeeper需保證高可用和強(qiáng)一致性；

? 為了支持更多的客戶端，需要增加更多Server；

? Server增多，投票階段延遲增大，影響性能；

? 權(quán)衡伸縮性和高吞吐率，引入Observer

? Observer不參與投票；

? Observers接受客戶端的連接，并將寫請(qǐng)求轉(zhuǎn)發(fā)給leader節(jié)點(diǎn)；

? 加入更多Observer節(jié)點(diǎn)，提高伸縮性，同時(shí)不影響吞吐率

8、 為什么zookeeper集群的數(shù)目，一般為奇數(shù)個(gè)？

?Leader選舉算法采用了Paxos協(xié)議；

?Paxos核心思想：當(dāng)多數(shù)Server寫成功，則任務(wù)數(shù)據(jù)寫成功如果有3個(gè)Server，則兩個(gè)寫成功即可；如果有4或5個(gè)Server，則三個(gè)寫成功即可。

?Server數(shù)目一般為奇數(shù)（3、5、7）如果有3個(gè)Server，則最多允許1個(gè)Server掛掉；如果有4個(gè)Server，則同樣最多允許1個(gè)Server掛掉由此，

我們看出3臺(tái)服務(wù)器和4臺(tái)服務(wù)器的的容災(zāi)能力是一樣的，所以為了節(jié)省服務(wù)器資源，一般我們采用奇數(shù)個(gè)數(shù)，作為服務(wù)器部署個(gè)數(shù)。

9、Zookeeper 的數(shù)據(jù)模型

? 層次化的目錄結(jié)構(gòu)，命名符合常規(guī)文件系統(tǒng)規(guī)范

? 每個(gè)節(jié)點(diǎn)在zookeeper中叫做znode,并且其有一個(gè)唯一的路徑標(biāo)識(shí)

? 節(jié)點(diǎn)Znode可以包含數(shù)據(jù)和子節(jié)點(diǎn)，但是EPHEMERAL類型的節(jié)點(diǎn)不能有子節(jié)點(diǎn)

? Znode中的數(shù)據(jù)可以有多個(gè)版本，比如某一個(gè)路徑下存有多個(gè)數(shù)據(jù)版本，那么查詢這個(gè)路徑下的數(shù)據(jù)就需要帶上版本

? 客戶端應(yīng)用可以在節(jié)點(diǎn)上設(shè)置監(jiān)視器

? 節(jié)點(diǎn)不支持部分讀寫，而是一次性完整讀寫

10、Zookeeper 的節(jié)點(diǎn)

? Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）

? Znode的類型在創(chuàng)建時(shí)確定并且之后不能再修改

? 短暫znode的客戶端會(huì)話結(jié)束時(shí)，zookeeper會(huì)將該短暫znode刪除，短暫znode不可以有子節(jié)點(diǎn)

? 持久znode不依賴于客戶端會(huì)話，只有當(dāng)客戶端明確要?jiǎng)h除該持久znode時(shí)才會(huì)被刪除

? Znode有四種形式的目錄節(jié)點(diǎn)

? PERSISTENT（持久的）

? EPHEMERAL（暫時(shí)的）

? PERSISTENT_SEQUENTIAL（持久化順序編號(hào)目錄節(jié)點(diǎn)）

? EPHEMERAL_SEQUENTIAL（暫時(shí)化順序編號(hào)目錄節(jié)點(diǎn)）

Zookeeper的應(yīng)用場景

1. 配置管理

這個(gè)好理解，分布式系統(tǒng)都有好多機(jī)器，比如我在搭建hadoop的HDFS的時(shí)候，需要在一個(gè)主機(jī)器上（Master節(jié)點(diǎn)）配置好HDFS需要的各種配置文件，然后通過scp命令把這些配置文件拷貝到其他節(jié)點(diǎn)上，這樣各個(gè)機(jī)器拿到的配置信息是一致的，才能成功運(yùn)行起來HDFS服務(wù)。

Zookeeper提供了這樣的一種服務(wù)：一種集中管理配置的方法，我們?cè)谶@個(gè)集中的地方修改了配置，所有對(duì)這個(gè)配置感興趣的都可以獲得變更。這樣就省去手動(dòng)拷貝配置了，還保證了可靠和一致性。

2. 名字服務(wù)

這個(gè)可以簡單理解為一個(gè)電話薄，電話號(hào)碼不好記，但是人名好記，要打誰的電話，直接查人名就好了。

分布式環(huán)境下，經(jīng)常需要對(duì)應(yīng)用/服務(wù)進(jìn)行統(tǒng)一命名，便于識(shí)別不同服務(wù)；

• 類似于域名與ip之間對(duì)應(yīng)關(guān)系，域名容易記住；
• 通過名稱來獲取資源或服務(wù)的地址，提供者等信息

3. 分布式鎖

碰到分布二字貌似就難理解了，其實(shí)很簡單。單機(jī)程序的各個(gè)進(jìn)程需要對(duì)互斥資源進(jìn)行訪問時(shí)需要加鎖，那分布式程序分布在各個(gè)主機(jī)上的進(jìn)程對(duì)互斥資源進(jìn)行訪問時(shí)也需要加鎖。很多分布式系統(tǒng)有多個(gè)可服務(wù)的窗口，但是在某個(gè)時(shí)刻只讓一個(gè)服務(wù)去干活，當(dāng)這臺(tái)服務(wù)出問題的時(shí)候鎖釋放，立即fail over到另外的服務(wù)。這在很多分布式系統(tǒng)中都是這么做，這種設(shè)計(jì)有一個(gè)更好聽的名字叫Leader Election（leader選舉）。舉個(gè)通俗點(diǎn)的例子，比如銀行取錢，有多個(gè)窗口，但是呢對(duì)你來說，只能有一個(gè)窗口對(duì)你服務(wù)，如果正在對(duì)你服務(wù)的窗口的柜員突然有急事走了，那咋辦？找大堂經(jīng)理（zookeeper）!大堂經(jīng)理指定另外的一個(gè)窗口繼續(xù)為你服務(wù)！

4. 集群管理

在分布式的集群中，經(jīng)常會(huì)由于各種原因，比如硬件故障，軟件故障，網(wǎng)絡(luò)問題，有些節(jié)點(diǎn)會(huì)進(jìn)進(jìn)出出。有新的節(jié)點(diǎn)加入進(jìn)來，也有老的節(jié)點(diǎn)退出集群。這個(gè)時(shí)候，集群中有些機(jī)器（比如Master節(jié)點(diǎn)）需要感知到這種變化，然后根據(jù)這種變化做出對(duì)應(yīng)的決策。我已經(jīng)知道HDFS中namenode是通過datanode的心跳機(jī)制來實(shí)現(xiàn)上述感知的，那么我們可以先假設(shè)Zookeeper其實(shí)也是實(shí)現(xiàn)了類似心跳機(jī)制的功能吧！

你可能也喜歡:

如何從0到1設(shè)計(jì)一個(gè)類Dubbo的RPC框架

阿里P8架構(gòu)師談：從單體架構(gòu)、到SOA、再到微服務(wù)的架構(gòu)設(shè)計(jì)詳解

阿里P8架構(gòu)師談：微服務(wù)Dubbo和SpringCloud架構(gòu)設(shè)計(jì)、優(yōu)劣勢比較

阿里P8架構(gòu)師談：Spring Cloud與Dubbo的詳細(xì)比較

RPC框架的實(shí)現(xiàn)原理，及RPC架構(gòu)組件詳解

阿里P8架構(gòu)師談：Restful、SOAP、RPC、SOA、微服務(wù)之間的區(qū)別

---

總結(jié)

以上是生活随笔為你收集整理的阿里P8架构师谈：Zookeeper的原理和架构设计，以及应用场景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。