分散式服務框架Zookeeper介紹、原理及應用
轉載：https://www.jianshu.com/p/bf32e44d3113
分散式服務框架Zookeeper介紹、原理及應用
Zookeeper簡介
Zookeeper 分散式服務框架是 Apache Hadoop 的一個子專案，它主要是用來解決分散式應用中經常遇到的一些資料管理問題，如：統一命名服務、狀態同步服務、叢集管理、分散式應用配置項的管理等等。
Zookeeper基本概念
zk角色
Zookeeper中的角色主要有以下三類，如下表所示：
zookeeper角色
zk service網路結構
Zookeeper的工作叢集可以簡單分成兩類，一個是Leader，唯一一個，其餘的都是follower，如何確定Leader是通過內部選舉確定的。
zookeeper服務
- Leader和各個follower是互相通訊的，對於zk系統的資料都是儲存在記憶體裡面的，同樣也會備份一份在磁碟上。
對於每個zk節點而言，可以看做每個zk節點的名稱空間是一樣的，也就是有同樣的資料。（可檢視下面的樹結構）
- 如果Leader掛了，zk叢集會重新選舉，在毫秒級別就會重新選舉出一個Leaer。
- 叢集中除非有一半以上的zk節點掛了，zk service才不可用。
zk名稱空間結構
Zookeeper的名稱空間就是zk應用的檔案系統，它和linux的檔案系統很像，也是樹狀，這樣就可以確定每個路徑都是唯一的，對於名稱空間的操作必須都是絕對路徑操作。與linux檔案系統不同的是，linux檔案系統有目錄和檔案的區別，而zk統一叫做znode，一個znode節點可以包含子znode，同時也可以包含資料。
zookeeper樹結構
提示：
比如/Nginx/conf，/是一個znode，/Nginx是/的子znode，/Nginx還可以包含資料，資料內容就是所有安裝Nginx的機器IP，/Nginx/conf是/Nginx子znode，它也可以包含內容，資料就是Nginx的配置檔案內容。在應用中，我們可以通過這樣一個路徑就可以獲得所有安裝Nginx的機器IP列表，還可以獲得這些機器上Nginx的配置檔案。
zk讀寫資料
zookeeper讀寫資料
- 寫資料，但一個客戶端進行寫資料請求時，會指定zk叢集中節點，如果是follower接收到寫請求，就會把請求轉發給Leader，Leader通過內部的Zab協議進行原子廣播，直到所有zk節點都成功寫了資料後（記憶體同步以及磁碟更新），這次寫請求算是完成，然後zk service就會給client發回響應
- 讀資料，因為叢集中所有的zk節點都呈現一個同樣的名稱空間檢視（就是結構資料），上面的寫請求已經保證了寫一次資料必須保證叢集所有的zk節點都是同步名稱空間的，所以讀的時候可以在任意一臺zk節點上
ps:其實寫資料的時候不是要保證所有zk節點都寫完才響應，而是保證一半以上的節點寫完了就把這次變更更新到記憶體，並且當做最新名稱空間的應用。所以在讀資料的時候可能會讀到不是最新的zk節點，這時候只能通過sync()解決。這裡先不考慮了，假設整個zk service都是同步meta資訊的，後面的文章再討論。
zk znode型別
Zookeeper中znode的節點建立時候是可以指定型別的，主要有下面幾種型別。
- PERSISTENT：持久化znode節點，一旦建立這個znode點儲存的資料不會主動消失，除非是客戶端主動的delete。
SEQUENCE：順序增加編號znode節點，比如ClientA去zk service上建立一個znode名字叫做/Nginx/conf，指定了這種型別的節點後zk會建立/Nginx/conf0000000000，ClientB再去建立就是建立/Nginx/conf0000000001，ClientC是建立/Nginx/conf0000000002，以後任意Client來建立這個znode都會得到一個比當前zk名稱空間最大znode編號+1的znode，也就說任意一個Client去建立znode都是保證得到的znode是遞增的，而且是唯一的。
- EPHEMERAL：臨時znode節點，Client連線到zk service的時候會建立一個session，之後用這個zk連線例項建立該型別的znode，一旦Client關閉了zk的連線，伺服器就會清除session，然後這個session建立的znode節點都會從名稱空間消失。總結就是，這個型別的znode的生命週期是和Client建立的連線一樣的。比如ClientA建立了一個EPHEMERAL的/Nginx/conf0000000011的znode節點，一旦ClientA的zk連線關閉，這個znode節點就會消失。整個zk service名稱空間裡就會刪除這個znode節點。
- PERSISTENT|SEQUENTIAL：順序自動編號的znode節點，這種znoe節點會根據當前已近存在的znode節點編號自動加 1，而且不會隨session斷開而消失。
- EPHEMERAL|SEQUENTIAL：臨時自動編號節點，znode節點編號會自動增加，但是會隨session消失而消失
Zookeeper設計目的
- 最終一致性：client不論連線到哪個Server，展示給它都是同一個檢視，這是zookeeper最重要的效能。
- 可靠性：具有簡單、健壯、良好的效能，如果訊息m被到一臺伺服器接受，那麼它將被所有的伺服器接受。
- 實時性：Zookeeper保證客戶端將在一個時間間隔範圍內獲得伺服器的更新資訊，或者伺服器失效的資訊。但由於網路延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。
- 等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
- 原子性：更新只能成功或者失敗，沒有中間狀態。
- 順序性：包括全域性有序和偏序兩種：全域性有序是指如果在一臺伺服器上訊息a在訊息b前釋出，則在所有Server上訊息a都將在訊息b前被髮布；偏序是指如果一個訊息b在訊息a後被同一個傳送者釋出，a必將排在b前面。
Zookeeper工作原理
Zookeeper 的核心是廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。
Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播 模式（同步）。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後， 恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。為了保證事務的順序一致性，zookeeper採用了遞增的事務id號 （zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用 來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態：
- LOOKING：當前Server不知道leader是誰，正在搜尋。
- LEADING：當前Server即為選舉出來的leader。
- FOLLOWING：leader已經選舉出來，當前Server與之同步。
選主流程
當 leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的 Server都恢復到一個正確的狀態。
Zookeeper的選舉演算法有兩種：
一種是基於basic paxos實現的，另外一種是基於fast paxos演算法實現的。
系統預設的選舉演算法為fast paxos。
basic paxos流程：
- 選舉執行緒由當前Server發起選舉的執行緒擔任，其主要功能是對投票結果進行統計，並選出推薦的Server；
- 選舉執行緒首先向所有Server發起一次詢問(包括自己)；
- 選舉執行緒收到回覆後，驗證是否是自己發起的詢問(驗證zxid是否一致)，然後獲取對方的id(myid)，並存儲到當前詢問物件列表中，最後獲取對方提議的leader相關資訊(id,zxid)，並將這些資訊儲存到當次選舉的投票記錄表中；
- 收到所有Server回覆以後，就計算出zxid最大的那個Server，並將這個Server相關資訊設定成下一次要投票的Server；
- 執行緒將當前zxid最大的Server設定為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數， 設定當前推薦的leader為獲勝的Server，將根據獲勝的Server相關資訊設定自己的狀態，否則，繼續這個過程，直到leader被選舉出來。通 過流程分析我們可以得出：要使Leader獲得多數Server的支援，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於 n+1.每個Server啟動後都會重複以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁碟快照中恢復資料和會話信 息，zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復。
選舉的具體流程圖如下所示：
zk basic paxos選舉
fast paxos流程：
在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以後，解決epoch和 zxid的衝突，並接受對方的提議，然後向對方傳送接受提議完成的訊息，重複這個流程，最後一定能選舉出Leader。
選舉的具體流程圖如下所示：
zk fast paxos選舉
同步流程
選完leader以後，zk就進入狀態同步過程。
- leader等待server連線；
- Follower連線leader，將最大的zxid傳送給leader；
- Leader根據follower的zxid確定同步點；
- 完成同步後通知follower 已經成為uptodate狀態；
- Follower收到uptodate訊息後，又可以重新接受client的請求進行服務了。
同步的具體流程圖如下所示：
zk同步流程
工作流程
Leader工作流程
- 恢復資料；
- 維持與Learner的心跳，接收Learner請求並判斷Learner的請求訊息型別；
- Learner的訊息型別主要有PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息，根據不同的訊息型別，進行不同的處理。
PING 訊息是指Learner的心跳資訊；
REQUEST訊息是Follower傳送的提議資訊，包括寫請求及同步請求；
ACK訊息是Follower的對提議 的回覆，超過半數的Follower通過，則commit該提議；
REVALIDATE訊息是用來延長SESSION有效時間。
Leader的工作流程簡圖具體如下所示：
Leader工作流程
Follower工作流程
Follower主要有四個功能：
- 向Leader傳送請求（PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息）；
- 接收Leader訊息並進行處理；
- 接收Client的請求，如果為寫請求，傳送給Leader進行投票；
- 返回Client結果。
Follower的訊息迴圈處理如下幾種來自Leader的訊息：
- PING訊息： 心跳訊息；
- PROPOSAL訊息：Leader發起的提案，要求Follower投票；
- COMMIT訊息：伺服器端最新一次提案的資訊；
- UPTODATE訊息：表明同步完成；
- REVALIDATE訊息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受訊息；
- SYNC訊息：返回SYNC結果到客戶端，這個訊息最初由客戶端發起，用來強制得到最新的更新。
Follower的工作流程簡圖具體如下所示：
Follower的工作流程
應用篇
分散式系統的執行是很複雜的，因為涉及到了網路通訊還有節點失效等不可控的情況。下面介紹在最傳統的master-workers模型，主要可以會遇到什麼問題，傳統方法是怎麼解決以及怎麼用zookeeper解決。
Master節點管理
叢集當中最重要的是Master，所以一般都會設定一臺Master的Backup。
Backup會定期向Master獲取Meta資訊並且檢測Master的存活性，一旦Master掛了，Backup立馬啟動，接替Master的工作自己成為Master，分散式的情況多種多樣，因為涉及到了網路通訊的抖動，針對下面的情況:
- Backup檢測Master存活性傳統的就是定期發包，一旦一定時間段內沒有收到響應就判定Master Down了，於是Backup就啟動，如果Master其實是沒有down，Backup收不到響應或者收到響應延遲的原因是因為網路阻塞的問題呢？Backup也啟動了，這時候叢集裡就有了兩個Master，很有可能部分workers彙報給Master，另一部分workers彙報給後來啟動的Backup，這下子服務就全亂了。
- Backup是定期同步Master中的meta資訊，所以總是滯後的，一旦Master掛了，Backup的資訊必然是老的，很有可能會影響叢集執行狀態。
解決問題:
Master節點高可用，並且保證唯一。
Meta資訊的及時同步。
** Zookeeper Master選舉 **
Zookeeper會分配給註冊到它上面的客戶端一個編號，並且zk自己會保證這個編號的唯一性和遞增性，N多機器中只需選出編號最小的Client作為Master就行，並且保證這些機器的都維護一個一樣的meta資訊檢視，一旦Master掛了，那麼這N機器中編號最小的勝任Master，Meta資訊是一致的。
叢集worker管理
叢集中的worker掛了是很可能的，一旦worker A掛了，如果存在其餘的workers互相之間需要通訊，那麼workers必須儘快更新自己的hosts列表，把掛了的worker剔除，從而不在和它通訊，而Master要做的是把掛了worker上的作業排程到其他的worker上。同樣的，這臺worker重新恢復正常了，要通知其他的workers更新hosts列表。傳統的作法都是有專門的監控系統，通過不斷去發心跳包(比如ping)來發現worker是否alive，缺陷就是及時性問題，不能應用於線上率要求較高的場景
解決問題:
叢集worker監控。
** Zookeeper監控叢集 **
利用zookeeper建立znode的強一致性，可以用於那種對叢集中機器狀態，機器線上率有較高要求的場景，能夠快速對叢集中機器變化作出響應。
分散式鎖
在一臺機器上要多個程序或者多個執行緒操作同一資源比較簡單，因為可以有大量的狀態資訊或者日誌資訊提供保證，比如兩個A和B程序同時寫一個檔案，加鎖就可以實現。但是分散式系統怎麼辦？需要一個三方的分配鎖的機制，幾百臺worker都對同一個網路中的檔案寫操作，怎麼協同？還有怎麼保證高效的執行？
解決問題:
高效分散式的分散式鎖
Zookeeper分散式鎖
分散式鎖主要得益於ZooKeeper為我們保證了資料的強一致性，zookeeper的znode節點建立的唯一性和遞增效能保證所有來搶鎖的worker的原子性。
配置檔案管理
叢集中配置檔案的更新和同步是很頻繁的，傳統的配置檔案分發都是需要把配置檔案資料分發到每臺worker上，然後進行worker的reload，這種方式是最笨的方式，結構很難維護，因為如果叢集當中有可能很多種應用的配置檔案要同步，而且效率很低，叢集規模一大負載很高。還有一種就是每次更新把配置檔案單獨儲存到一個數據庫裡面，然後worker端定期pull資料，這種方式就是資料及時性得不到同步。
解決問題:
統一配置檔案分發並且及時讓worker生效
Zookeeper釋出與訂閱模型
釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務地址列表等就非常適合使用。