阿里P8架構師談：Zookeeper的原理和架構設計，以及應用場景

隨著信息化水平的不斷提高，企業(yè)級應用系統(tǒng)變得越來越龐大，性能隨之下降，用戶抱怨頻頻。拆分系統(tǒng)是目前我們可選擇的解決系統(tǒng)可伸縮性和性能問題的唯一行之有效的方法。但是拆分系統(tǒng)同時也帶來了系統(tǒng)的復雜性——各子系統(tǒng)不是孤立存在的，它們彼此之間需要協(xié)作和交互（分布式系統(tǒng)）。各個子系統(tǒng)就好比動物園里的動物，為了使各個子系統(tǒng)能正常為用戶提供統(tǒng)一的服務，必須需要一種機制來進行協(xié)調(diào)——這就是ZooKeeper（動物園管理員）。下面詳解：


什么是 Zookeeper

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

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


Zookeeper的基本原理和架構

1、Zookeeper的角色
領導者（leader）：負責進行投票的發(fā)起和決議，更新系統(tǒng)狀態(tài)；
學習者（learner）：包括跟隨者（follower）和觀察者（observer），follower用于接受客戶端請求并想客戶端返回結果，在選主過程中參與投票；
Observer：可以接受客戶端連接，將寫請求轉(zhuǎn)發(fā)給leader，但observer不參加投票過程，只同步leader的狀態(tài)，observer的目的是為了擴展系統(tǒng)，提高讀取速度；
客戶端（client）：請求發(fā)起方。

創(chuàng)新互聯(lián)公司主營梨林網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,重慶App定制開發(fā),梨林h5小程序定制開發(fā)搭建,梨林網(wǎng)站營銷推廣歡迎梨林等地區(qū)企業(yè)咨詢

? Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復模式就結束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
? 為了保證事務的順序一致性，zookeeper采用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于那個leader的統(tǒng)治時期。低32位用于遞增計數(shù)。
? 每個Server在工作過程中有三種狀態(tài)：
LOOKING：當前Server不知道leader是誰，正在搜尋；
LEADING：當前Server即為選舉出來的leader；
FOLLOWING：leader已經(jīng)選舉出來，當前Server與之同步。

2、Zookeeper 的讀寫機制
Zookeeper是一個由多個server組成的集群；
一個leader，多個follower；
每個server保存一份數(shù)據(jù)副本；
全局數(shù)據(jù)一致；
分布式讀寫；
更新請求轉(zhuǎn)發(fā)，由leader實施。

3、Zookeeper 的保證
更新請求順序進行，來自同一個client的更新請求按其發(fā)送順序依次執(zhí)行；
數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失??；
全局唯一數(shù)據(jù)視圖，client無論連接到哪個server，數(shù)據(jù)視圖都是一致的；
實時性，在一定事件范圍內(nèi)，client能讀到最新數(shù)據(jù)。

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

在Client向Follwer發(fā)出一個寫的請求；
Follwer把請求發(fā)送給Leader；
Leader接收到以后開始發(fā)起投票并通知Follwer進行投票；
Follwer把投票結果發(fā)送給Leader；
Leader將結果匯總后如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然后commit;
Follwer把請求結果返回給Client。

5、Zookeeper工作原理
Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是：恢復模式和廣播模式。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數(shù)server的完成了和leader的狀態(tài)同步以后，恢復模式就結束了。

6、數(shù)據(jù)一致性與paxos 算法
? 據(jù)說Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持數(shù)據(jù)的一致性，這里有個原則就是：
? 在一個分布式數(shù)據(jù)庫系統(tǒng)中，如果各節(jié)點的初始狀態(tài)一致，每個節(jié)點都執(zhí)行相同的操作序列，那么他們最后能得到一個一致的狀態(tài)。
? Paxos算法解決的什么問題呢，解決的就是保證每個節(jié)點執(zhí)行相同的操作序列。好吧，這還不簡單，master維護一個全局寫隊列，所有寫操作都必須 放入這個隊列編號，那么無論我們寫多少個節(jié)點，只要寫操作是按編號來的，就能保證一致性。沒錯，就是這樣，可是如果master掛了呢。
? Paxos算法通過投票來對寫操作進行全局編號，同一時刻，只有一個寫操作被批準，同時并發(fā)的寫操作要去爭取選票，只有獲得過半數(shù)選票的寫操作才會被 批準（所以永遠只會有一個寫操作得到批準），其他的寫操作競爭失敗只好再發(fā)起一輪投票，就這樣，在日復一日年復一年的投票中，所有寫操作都被嚴格編號排 序。編號嚴格遞增，當一個節(jié)點接受了一個編號為100的寫操作，之后又接受到編號為99的寫操作（因為網(wǎng)絡延遲等很多不可預見原因），它馬上能意識到自己 數(shù)據(jù)不一致了，自動停止對外服務并重啟同步過程。任何一個節(jié)點掛掉都不會影響整個集群的數(shù)據(jù)一致性（總2n+1臺，除非掛掉大于n臺）。
總結：Zookeeper 作為 Hadoop 項目中的一個子項目，是 Hadoop 集群管理的一個必不可少的模塊，它主要用來控制集群中的數(shù)據(jù)，如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態(tài)同步等。

7、Observer
Zookeeper需保證高可用和強一致性；
為了支持更多的客戶端，需要增加更多Server；
Server增多，投票階段延遲增大，影響性能；
權衡伸縮性和高吞吐率，引入Observer；
Observer不參與投票；
Observers接受客戶端的連接，并將寫請求轉(zhuǎn)發(fā)給leader節(jié)點；
加入更多Observer節(jié)點，提高伸縮性，同時不影響吞吐率。

8、 為什么zookeeper集群的數(shù)目，一般為奇數(shù)個？
Leader選舉算法采用了Paxos協(xié)議；
Paxos核心思想：當多數(shù)Server寫成功，則任務數(shù)據(jù)寫成功如果有3個Server，則兩個寫成功即可；如果有4或5個Server，則三個寫成功即可；
Server數(shù)目一般為奇數(shù)（3、5、7）如果有3個Server，則最多允許1個Server掛掉；如果有4個Server，則同樣最多允許1個Server掛掉由此，我們看出3臺服務器和4臺服務器的的容災能力是一樣的，所以為了節(jié)省服務器資源，一般我們采用奇數(shù)個數(shù)，作為服務器部署個數(shù)。

9、Zookeeper 的數(shù)據(jù)模型　
層次化的目錄結構，命名符合常規(guī)文件系統(tǒng)規(guī)范；
每個節(jié)點在zookeeper中叫做znode,并且其有一個唯一的路徑標識；
節(jié)點Znode可以包含數(shù)據(jù)和子節(jié)點，但是EPHEMERAL類型的節(jié)點不能有子節(jié)點；
Znode中的數(shù)據(jù)可以有多個版本，比如某一個路徑下存有多個數(shù)據(jù)版本，那么查詢這個路徑下的數(shù)據(jù)就需要帶上版本；
客戶端應用可以在節(jié)點上設置監(jiān)視器；
節(jié)點不支持部分讀寫，而是一次性完整讀寫。

10、Zookeeper 的節(jié)點
Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）；
Znode的類型在創(chuàng)建時確定并且之后不能再修改；
短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節(jié)點；
持久znode不依賴于客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除；
Znode有四種形式的目錄節(jié)點；
PERSISTENT（持久的）；
EPHEMERAL(暫時的)；
PERSISTENT_SEQUENTIAL（持久化順序編號目錄節(jié)點）；
EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節(jié)點）。

Zookeeper的應用場景

1. 配置管理
這個好理解，分布式系統(tǒng)都有好多機器，比如我在搭建hadoop的HDFS的時候，需要在一個主機器上（Master節(jié)點）配置好HDFS需要的各種配置文件，然后通過scp命令把這些配置文件拷貝到其他節(jié)點上，這樣各個機器拿到的配置信息是一致的，才能成功運行起來HDFS服務。
Zookeeper提供了這樣的一種服務：一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。這樣就省去手動拷貝配置了，還保證了可靠和一致性。

2. 名字服務
這個可以簡單理解為一個電話薄，電話號碼不好記，但是人名好記，要打誰的電話，直接查人名就好了。分布式環(huán)境下，經(jīng)常需要對應用/服務進行統(tǒng)一命名，便于識別不同服務；
類似于域名與ip之間對應關系，域名容易記??；
通過名稱來獲取資源或服務的地址，提供者等信息。

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

4. 集群管理
在分布式的集群中，經(jīng)常會由于各種原因，比如硬件故障，軟件故障，網(wǎng)絡問題，有些節(jié)點會進進出出。有新的節(jié)點加入進來，也有老的節(jié)點退出集群。這個時候，集群中有些機器（比如Master節(jié)點）需要感知到這種變化，然后根據(jù)這種變化做出對應的決策。我已經(jīng)知道HDFS中namenode是通過datanode的心跳機制來實現(xiàn)上述感知的，那么我們可以先假設Zookeeper其實也是實現(xiàn)了類似心跳機制的功能吧！
更多高并發(fā)架構系列連載，內(nèi)容包括：java高并發(fā)、SOA、分布式集群、多線程、redis、數(shù)據(jù)庫分庫分表、負載均衡等。

當前名稱：阿里P8架構師談：Zookeeper的原理和架構設計，以及應用場景
本文路徑：http://muchs.cn/article34/jpijpe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、全網(wǎng)營銷推廣、企業(yè)建站、軟件開發(fā)、云服務器、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)