? ? ? ?本文是Hadoop生態(tài)體系組件之Zookeeper的學習總結性文章粉寞。因本人非技術出身化焕，所學均來源于網絡摄杂，難免有不嚴謹甚至錯誤之處坝咐，懇請大家指正。
? ? ? ?在上篇關于YARN的文章中我們提到了ZooKeeper,當時只是簡單的介紹了他是為了解決master/slave架構中的高可用問題的析恢，并沒做過多講解墨坚。那么此篇文章我將詳細的講解下ZooKeeper，包括其產生的背景映挂、應用場景以及部分原理以及其在Hadoop生態(tài)系統(tǒng)中扮演了什么樣的角色框杜。
什么是Zookeeper
? ? ? ?ZooKeeper是一個分布式的，開源的分布式應用程序協(xié)調服務（服務協(xié)調是分布式系統(tǒng)的基礎袖肥，它能夠解決leader選舉、服務發(fā)現(xiàn)振劳、分布式隊列椎组、分布式鎖等常見的分布式問題）
Zookeeper產生的背景
? ? ? ?Zookeeper源自雅虎研究所。當時历恐，研究人員發(fā)現(xiàn)雅虎系統(tǒng)中的許多系統(tǒng)很大程度上依賴于類似的分布式協(xié)作系統(tǒng)寸癌，但這些系統(tǒng)都存在分布式單點故障問題。因此弱贼，雅虎的開發(fā)人員開發(fā)了一個通用的分布式協(xié)調框架來解決這個問題蒸苇，這就是大名鼎鼎的Zookeeper。
Zookeeper存在的意義
? ? ? ?在分布式系統(tǒng)中吮旅，服務（或組件）之間的協(xié)調是非常重要的溪烤，它構成了分布式系統(tǒng)的基礎味咳。而ZooKeeper通常在分布式系統(tǒng)中擔任協(xié)調者的角色，比如leader選舉檬嘀、負載均衡槽驶、服務發(fā)現(xiàn)、分布式隊列（幫助我們實現(xiàn)跨進程鸳兽、跨主機掂铐、跨網絡的數(shù)據共享和數(shù)據傳遞的需求）和分布式鎖（為了防止分布式系統(tǒng)中的多個進程之間相互干擾，需要一種分布式協(xié)調技術來對這些進程進行調度揍异，而這個分布式協(xié)調技術的核心就是分布式鎖）等全陨，接下來以leader選舉和負載均衡為例，說明Zookeeper存在的意義及基本職責衷掷。
leader選舉：在分布式系統(tǒng)中辱姨，常見的一種軟件設計架構為master/slave，如上圖所示棍鳖，其中master負責集群管理炮叶，slave負責執(zhí)行具體的任務（比如存儲數(shù)據、處理數(shù)據）渡处，如前面的HDFS镜悉、YARN等均采用了該架構。這種架構存在一個明顯缺陷：master是單點医瘫。為了避免master出現(xiàn)故障導致整個集群不可用侣肄，常見的優(yōu)化方式是引入多master，比如雙master:active master和standby master醇份，其中active master對外提供服務稼锅，而standby master則作為備用master，一直處于“待命”狀態(tài)僚纷，一旦active master出現(xiàn)故障矩距，自己則切換為active master。
負載均衡：在類似于Kafka（后續(xù)文章會講到）的分布式消息隊列中,如上圖怖竭，生產者將數(shù)據寫入分布式隊列锥债，消費者從分布式消息隊列中讀取數(shù)據進行處理，為了實現(xiàn)該功能痊臭，需要從架構上解決以下兩個問題：
1）生產者和消費者如何獲知最新的消息隊列位置哮肚？消息隊列是分布式的，通常由一組節(jié)點構成广匙，這些節(jié)點的健康狀態(tài)是動態(tài)變化的允趟，比如某個節(jié)點因機器故障變得對外不可用，如何讓生產者和消費者動態(tài)獲知最新的消息隊列節(jié)點位置是必須要解決的問題鸦致。
2）如何讓生產者將數(shù)據均衡地寫入消息隊列中各個節(jié)點潮剪？消息隊列提供了一組可存儲數(shù)據的節(jié)點涣楷，需讓生產者及時了解各個存儲節(jié)點的負載，以便智能決策將數(shù)據均衡地寫入這些節(jié)點鲁纠。為了解決以上兩個問題总棵，需要引入一個可靠的分布式協(xié)調服務，它具備簡單的元信息存儲和動態(tài)獲取服務狀態(tài)等基本功能改含。通過leader選舉和負載均衡兩個常見的分布式問題情龄，我們可以了解到，協(xié)調服務對于一個分布式系統(tǒng)而言多重要捍壤。為了解決服務協(xié)調這一類通用問題骤视，ZooKeeper出現(xiàn)了，它將服務協(xié)調的職責從分布式系統(tǒng)中獨立出來鹃觉，以減少系統(tǒng)的耦合性和增強擴充性专酗。
Zookeeper在Hadoop體系中扮演的角色
? ? ? ?Hadoop是分布式系統(tǒng)，所以為了可以正常運作則需要有一個分布式協(xié)調服務盗扇。因此ZooKeeper就被用于提供協(xié)調服務的組件存在于Hadoop生態(tài)系統(tǒng)中祷肯。他可以幫助用戶輕易地實現(xiàn)前面提到leader選舉、分布式鎖疗隶、分布式隊列等功能佑笋。比如在HDFS中的NameNode高可用（leader選舉問題）、YARN中的ResourceManager高可用（leader選舉問題）斑鼻、HBase（leader選舉與分布式鎖等）等蒋纬。
Zookeeper架構及原理
? ? ? ?如圖下圖所示，ZooKeeper服務通常由奇數(shù)個ZooKeeper實例構成坚弱，其中一個實例為leader角色蜀备，其他為follower角色。
ZooKeeper讀寫數(shù)據的路徑如下：
讀路徑：任意一個ZooKeeper實例均可為客戶端提供讀服務荒叶。ZooKeeper實例數(shù)目越多碾阁，讀吞吐率越高。
寫路徑：任意一個ZooKeeeper實例均可接受客戶端的寫請求些楣，但需進一步轉發(fā)給leader協(xié)調完成分布式寫瓷蛙。ZooKeeper采用了ZAB協(xié)議，該協(xié)議規(guī)定戈毒，只要多數(shù)ZooKeeper實例寫成功，就認為本次寫是成功的横堡。這意味著埋市，如果一個集群中存在2N+1個ZooKeeper實例，只要其中N+1個實例寫成功命贴，則本次寫操作是成功的道宅，從容錯性角度看食听，這種情況下，集群的最大容忍失敗實例數(shù)目為N污茵。需要注意的是樱报，ZooKeeper實例數(shù)目越多，寫延遲越高泞当。
? ? ? ?當leader出現(xiàn)故障時迹蛤，ZooKeeper會通過ZAB協(xié)議發(fā)起新一輪的leader投票選舉，保證集群中始終有一個可用的leader襟士。ZooKeeper中多個實例中的內存數(shù)據并不是強一致的盗飒，它采用的ZAB協(xié)議只能保證，同一時刻至少多數(shù)節(jié)點中的數(shù)據是強一致的陋桂。為了讓客戶端讀到最新的數(shù)據逆趣，需給對應的ZooKeeper實例發(fā)送同步指令，強制其與leader同步數(shù)據嗜历。
? ? ? ?在ZooKeeper集群中宣渗，隨著ZooKeeper實例數(shù)目的增多，讀吞吐率升高梨州，但寫延遲增加（這是因為Zookeeper實例越多痕囱，和Leader的通信通道就越堵塞，而寫操作是要和Leader進行通訊的摊唇，Leader在更多的實例中選擇寫任務的執(zhí)行者的時間也可能更長咐蝇，因此導致了寫延遲變高）。為了解決集群擴展性導致寫性能下降的問題巷查，ZooKeeper引入了第三個角色：Observer有序。
? ? ? ?Observer并不參與投票過程，除此之外岛请，它的功能與follower類似：它可以接入正常的ZooKeeper集群旭寿，接收并處理客戶端讀請求，或將寫請求進一步轉發(fā)給leader處理崇败。由于Observer自身能夠保存一份數(shù)據提供讀服務盅称，因此可通過增加Observer實例數(shù)提高系統(tǒng)的讀吞吐率。由于Observer不參與投票過程后室，因此它出現(xiàn)故障并不會影響ZooKeeper集群的可用性缩膝。Observer常見應用場景如下(此處沒太懂，等以后找人問清楚后再以簡單易懂的語言來解釋)：
(1) 作為數(shù)據中心間的橋梁: 由于數(shù)據中心之間的確定性通信延遲岸霹，將一個ZooKeeper部署到兩個數(shù)據中心會誤報網絡故障和網絡分區(qū)導致ZooKeeper不穩(wěn)定疾层。然而，如果將整個ZooKeeper集群部署到單獨一個集群中贡避，另一個集群只部署Observer痛黎，則可輕易地解決網絡分區(qū)問題
(2)作為消息總線:可將ZooKeeper作為一個可靠的消息總線使用予弧，Observer作為一種天然的可插拔組件能夠動態(tài)接入ZooKeeper集群，通過內置的發(fā)布訂閱機制近實時獲取新的消息湖饱。
Zookeeper應用案例
1.leader選舉
? ? ? ?在Hadoop生態(tài)系統(tǒng)中掖蛤，HBase、YARN和HDFS等系統(tǒng)井厌，采用了類似的機制解決leader選舉問題蚓庭，因前面提到過就略過啦！
2. 分布式隊列
? ? ? ?在分布式計算系統(tǒng)中旗笔，常見的做法是彪置，用戶將作業(yè)提交給系統(tǒng)的Master，并由Master將之分解成子任務后蝇恶，調度給各個Worker執(zhí)行拳魁。該方法存在一個問題：Master維護了所有作業(yè)和Worker信息，一旦Master出現(xiàn)故障撮弧，則整個集群不可用潘懊。為了避免Master維護過多狀態(tài)（這里的狀態(tài)可以簡單的理解成任務的信息，包括需要做什么贿衍，做了什么授舟，還需要做什么這種信息），一種改進方式是將所有信息保存到ZooKeeper上贸辈，進而讓Master變得無狀態(tài)释树，這使得leader選舉過程更加容易。如下圖
? ? ? ?該方案的關鍵是借助ZooKeeper實現(xiàn)一個分布式隊列擎淤，并借助ZooKeeper自帶的特性奢啥，維護作業(yè)提交順序、作業(yè)優(yōu)先級嘴拢、各節(jié)點（Worker）負載情況等桩盲。借助ZooKeeper自動編號特性，可輕易實現(xiàn)一個簡易的FIFO（First In First Out）隊列席吴，在這個隊列中赌结，編號小的作業(yè)總是先于編號大的作業(yè)提交。
3. 負載均衡
? ? ? ?分布式系統(tǒng)很容易通過ZooKeeper實現(xiàn)負載均衡孝冒，典型的應用場景是分布式消息隊列柬姚。在Kafka中，各個Broker和Consumer均會向ZooKeeper注冊庄涡，保存自己的相關信息量承，組件之間可動態(tài)獲取對方的信息。（后續(xù)會專門講Kafka）
4. 配置管理
? ? ? ?配置管理模塊是很多分布式系統(tǒng)的基礎，它的主要功能是將用戶更新的配置文件實時同步到各個節(jié)點的服務上宴合，以便它們近似實時的加載這些配置（我曾經負責過類似的分布式配置平臺，類似于阿里云的ACM迹鹅，有興趣的朋友可以去看他們的官方文檔）卦洽，典型架構如下圖所示：
配置管理模塊的工作流程如下：
1）服務啟動后，ConfigFetcher模塊與ZooKeeper服務通信斜棚，讀取znode節(jié)點/serviceA/conf中保存的配置數(shù)據阀蒂，并向該znode注冊一個watcher以監(jiān)聽其數(shù)據的改動。
2）用戶通過ConfigUpdater動態(tài)修改znode節(jié)點/serviceA/conf中的數(shù)據弟蚀。
3）各個服務收到配置數(shù)據變動通知蚤霞，讀取新的配置數(shù)據。
參考資料：《大數(shù)據技術體系詳解：原理义钉、架構與實踐》 作者：董西成
這本書寫的真的太贊了昧绣，我個人感覺也很適合技術基礎一般的新手去讀！再次感謝作者提供了這么好的書捶闸！
