ZooKeeper能夠用來作什麼（轉）

在ZooKeeper的官網上有這麼一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

這大概描述了ZooKeeper主要能夠幹哪些事情：配置管理，名字服務，提供分佈式同步以及集羣管理。那這些服務又究竟是什麼呢？咱們爲何須要這樣的服務？咱們又爲何要使用ZooKeeper來實現呢，使用ZooKeeper有什麼優點？接下來我會挨個介紹這些究竟是什麼，以及有哪些開源系統中使用了。

概念：

配置管理：在咱們的應用中除了代碼外，還有一些就是各類配置。好比數據庫鏈接等。通常咱們都是使用配置文件的方式，在代碼中引入這些配置文件。可是當咱們只有一種配置，只有一臺服務器，而且不常常修改的時候，使用配置文件是一個很好的作法，可是若是咱們配置很是多，有不少服務器都須要這個配置，並且還多是動態的話使用配置文件就不是個好主意了。這個時候每每須要尋找一種集中管理配置的方法，咱們在這個集中的地方修改了配置，全部對這個配置感興趣的均可以得到變動。好比咱們能夠把配置放在數據庫裏，而後全部須要配置的服務都去這個數據庫讀取配置。可是，由於不少服務的正常運行都很是依賴這個配置，因此須要這個集中提供配置服務的服務具有很高的可靠性。通常咱們能夠用一個集羣來提供這個配置服務，可是用集羣提高可靠性，那如何保證配置在集羣中的一致性呢？ 這個時候就須要使用一種實現了一致性協議的服務了。ZooKeeper就是這種服務，它使用Zab這種一致性協議來提供一致性。如今有不少開源項目使用ZooKeeper來維護配置，好比在HBase中，客戶端就是鏈接一個ZooKeeper，得到必要的HBase集羣的配置信息，而後才能夠進一步操做。還有在開源的消息隊列Kafka中，也使用ZooKeeper來維護broker的信息。在Alibaba開源的SOA框架Dubbo中也普遍的使用ZooKeeper管理一些配置來實現服務治理。

名字服務：名字服務這個就很好理解了。好比爲了經過網絡訪問一個系統，咱們得知道對方的IP地址，可是IP地址對人很是不友好，這個時候咱們就須要使用域名來訪問。可是計算機是不能是別域名的。怎麼辦呢？若是咱們每臺機器裏都備有一份域名到IP地址的映射，這個卻是能解決一部分問題，可是若是域名對應的IP發生變化了又該怎麼辦呢？因而咱們有了DNS這個東西。咱們只須要訪問一個你們熟知的(known)的點，它就會告訴你這個域名對應的IP是什麼。在咱們的應用中也會存在不少這類問題，特別是在咱們的服務特別多的時候，若是咱們在本地保存服務的地址的時候將很是不方便，可是若是咱們只須要訪問一個你們都熟知的訪問點，這裏提供統一的入口，那麼維護起來將方便得多了。

分佈式鎖：其實在第一篇文章中已經介紹了ZooKeeper是一個分佈式協調服務。這樣咱們就能夠利用ZooKeeper來協調多個分佈式進程之間的活動。好比在一個分佈式環境中，爲了提升可靠性，咱們的集羣的每臺服務器上都部署着一樣的服務。可是，一件事情若是集羣中的每一個服務器都進行的話，那相互之間就要協調，編程起來將很是複雜。而若是咱們只讓一個服務進行操做，那又存在單點。一般還有一種作法就是使用分佈式鎖，在某個時刻只讓一個服務去幹活，當這臺服務出問題的時候鎖釋放，當即fail over到另外的服務。這在不少分佈式系統中都是這麼作，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。好比HBase的Master就是採用這種機制。但要注意的是分佈式鎖跟同一個進程的鎖仍是有區別的，因此使用的時候要比同一個進程裏的鎖更謹慎的使用。

集羣管理：在分佈式的集羣中，常常會因爲各類緣由，好比硬件故障，軟件故障，網絡問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集羣。這個時候，集羣中其餘機器須要感知到這種變化，而後根據這種變化作出對應的決策。好比咱們是一個分佈式存儲系統，有一箇中央控制節點負責存儲的分配，當有新的存儲進來的時候咱們要根據如今集羣目前的狀態來分配存儲節點。這個時候咱們就須要動態感知到集羣目前的狀態。還有，好比一個分佈式的SOA架構中，服務是一個集羣提供的，當消費者訪問某個服務時，就須要採用某種機制發現如今有哪些節點能夠提供該服務(這也稱之爲服務發現，好比Alibaba開源的SOA框架Dubbo就採用了ZooKeeper做爲服務發現的底層機制)。還有開源的Kafka隊列就採用了ZooKeeper做爲Cosnumer的上下線管理。

實際運用場景：

場景一：有一組服務器向客戶端提供某種服務（例如：我前面作的分佈式網站的服務端，就是由四臺服務器組成的集羣，向前端集羣提供服務），咱們但願客戶端每次請求服務端均可以找到服務端集羣中某一臺服務器，這樣服務端就能夠向客戶端提供客戶端所需的服務。對於這種場景，咱們的程序中必定有一份這組服務器的列表，每次客戶端請求時候，都是從這份列表裏讀取這份服務器列表。那麼這分列表顯然不能存儲在一臺單節點的服務器上，不然這個節點掛掉了，整個集羣都會發生故障，咱們但願這份列表時高可用的。高可用的解決方案是：這份列表是分佈式存儲的，它是由存儲這份列表的服務器共同管理的，若是存儲列表裏的某臺服務器壞掉了，其餘服務器立刻能夠替代壞掉的服務器，而且能夠把壞掉的服務器從列表裏刪除掉，讓故障服務器退出整個集羣的運行，而這一切的操做又不會由故障的服務器來操做，而是集羣里正常的服務器來完成。這是一種主動的分佈式數據結構，可以在外部狀況發生變化時候主動修改數據項狀態的數據機構。ZooKeeper框架提供了這種服務。這種服務名字就是：統一命名服務，它和javaEE裏的JNDI服務很像。

場景二：分佈式鎖服務。當分佈式系統操做數據，例如：讀取數據、分析數據、最後修改數據。在分佈式系統裏這些操做可能會分散到集羣裏不一樣的節點上，那麼這時候就存在數據操做過程當中一致性的問題，若是不一致，咱們將會獲得一個錯誤的運算結果，在單一進程的程序裏，一致性的問題很好解決，可是到了分佈式系統就比較困難，由於分佈式系統裏不一樣服務器的運算都是在獨立的進程裏，運算的中間結果和過程還要經過網絡進行傳遞，那麼想作到數據操做一致性要困難的多。ZooKeeper提供了一個鎖服務解決了這樣的問題，能讓咱們在作分佈式數據運算時候，保證數據操做的一致性。

場景三：配置管理。在分佈式系統裏，咱們會把一個服務應用分別部署到n臺服務器上，這些服務器的配置文件是相同的（例如：我設計的分佈式網站框架裏，服務端就有4臺服務器，4臺服務器上的程序都是同樣，配置文件都是同樣），若是配置文件的配置選項發生變化，那麼咱們就得一個個去改這些配置文件，若是咱們須要改的服務器比較少，這些操做還不是太麻煩，若是咱們分佈式的服務器特別多，好比某些大型互聯網公司的hadoop集羣有數千臺服務器，那麼更改配置選項就是一件麻煩並且危險的事情。這時候ZooKeeper就能夠派上用場了，咱們能夠把ZooKeeper當成一個高可用的配置存儲器，把這樣的事情交給ZooKeeper進行管理，咱們將集羣的配置文件拷貝到ZooKeeper的文件系統的某個節點上，而後用ZooKeeper監控全部分佈式系統裏配置文件的狀態，一旦發現有配置文件發生了變化，每臺服務器都會收到ZooKeeper的通知，讓每臺服務器同步ZooKeeper裏的配置文件，ZooKeeper服務也會保證同步操做原子性，確保每一個服務器的配置文件都能被正確的更新。

場景四：爲分佈式系統提供故障修復的功能。集羣管理是很困難的，在分佈式系統里加入了ZooKeeper服務，能讓咱們很容易的對集羣進行管理。集羣管理最麻煩的事情就是節點故障管理，ZooKeeper可讓集羣選出一個健康的節點做爲master，master節點會知道當前集羣的每臺服務器的運行情況，一旦某個節點發生故障，master會把這個狀況通知給集羣其餘服務器，從而從新分配不一樣節點的計算任務。ZooKeeper不只能夠發現故障，也會對有故障的服務器進行甄別，看故障服務器是什麼樣的故障，若是該故障能夠修復，ZooKeeper能夠自動修復或者告訴系統管理員錯誤的緣由讓管理員迅速定位問題，修復節點的故障。你們也許還會有個疑問，master故障了，那怎麼辦了？ZooKeeper也考慮到了這點，ZooKeeper內部有一個「選舉領導者的算法」，master能夠動態選擇，當master故障時候，ZooKeeper能立刻選出新的master對集羣進行管理。

ZooKeeper的特色：

一、ZooKeeper是一個精簡的文件系統。這點它和Hadoop有點像，可是ZooKeeper這個文件系統是管理小文件的，而Hadoop是管理超大文件的。

二、ZooKeeper提供了豐富的「構件」，這些構件能夠實現不少協調數據結構和協議的操做。例如：分佈式隊列、分佈式鎖以及一組同級節點的「領導者選舉」算法。

三、ZooKeeper是高可用的，它自己的穩定性是至關之好，分佈式集羣徹底能夠依賴ZooKeeper集羣的管理，利用ZooKeeper避免分佈式系統的單點故障的問題。

四、ZooKeeper採用了鬆耦合的交互模式。這點在ZooKeeper提供分佈式鎖上表現最爲明顯，ZooKeeper能夠被用做一個約會機制，讓參入的進程不在了解其餘進程的（或網絡）的狀況下可以彼此發現並進行交互，參入的各方甚至沒必要同時存在，只要在ZooKeeper留下一條消息，在該進程結束後，另一個進程還能夠讀取這條信息，從而解耦了各個節點之間的關係。

五、ZooKeeper爲集羣提供了一個共享存儲庫，集羣能夠從這裏集中讀寫共享的信息，避免了每一個節點的共享操做編程，減輕了分佈式系統的開發難度。

六、ZooKeeper的設計採用的是觀察者的設計模式，ZooKeeper主要是負責存儲和管理你們關心的數據，而後接受觀察者的註冊，一旦這些數據的狀態發生變化，ZooKeeper就將負責通知已經在ZooKeeper上註冊的那些觀察者作出相應的反應，從而實現集羣中相似Master/Slave管理模式。

因而可知ZooKeeper很利於分佈式系統開發，它能讓分佈式系統更加健壯和高效。

 

參考：

http://www.cnblogs.com/yuyijq/p/3424473.html（以上小部份內容轉自此篇文章）

http://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html（以上大部份內容轉自此篇文章）