zookeeper技術淺析

　Zookeeper是hadoop的一個子項目，儘管源自hadoop，但是我發現zookeeper脫離hadoop的範疇開發分佈式框架的運用愈來愈多。

今天我想談談zookeeper。本文不談如何使用zookeeper。而是zookeeper究竟有哪些實際的運用，哪些類型的應用能發揮zookeeper的優點，最後談談zookeeper對分佈式站點架構能產生如何的做用。

　　Zookeeper是針對大型分佈式系統的高可靠的協調系統。

由這個定義咱們知道zookeeper是個協調系統，做用的對象是分佈式系統。爲何分佈式系統需要一個協調系統了？理由例如如下：

　　開發分佈式系統是件很是困難的事情，當中的困難主要體現在分佈式系統的「部分失敗」。「部分失敗」是指信息在網絡的兩個節點之間傳送時候，假設網絡出了故障，發送者沒法知道接收者是否收到了這個信息。而且這樣的故障的緣由很是複雜。接收者可能在出現網絡錯誤以前已經收到了信息，也可能沒有收到，又或接收者的進程死掉了。

發送者能夠得到真實狀況的惟一辦法就是又一次鏈接到接收者，詢問接收者錯誤的緣由，這就是分佈式系統開發裏的「部分失敗」問題。

　　Zookeeper就是解決分佈式系統「部分失敗」的框架。

Zookeeper不是讓分佈式系統避免「部分失敗」問題，而是讓分佈式系統當碰到部分失敗時候。可以正確的處理此類的問題，讓分佈式系統能正常的執行。

　　如下我要講講zookeeper的實際運用場景：

　　場景一：有一組server向client提供某種服務（好比：我前面作的分佈式站點的服務端。就是由四臺server組成的集羣，向前端集羣提供服務）。咱們但願client每次請求服務端都可以找到服務端集羣中某一臺server，這樣服務端就可以向client提供client所需的服務。

對於這樣的場景，咱們的程序中必定有一份這組server的列表。每次client請求時候，都是從這份列表裏讀取這份server列表。

那麼這分列表顯然不能存儲在一臺單節點的server上。不然這個節點掛掉了，整個集羣都會發生問題，咱們但願這份列表時高可用的。

高可用的解決方式是：這份列表是分佈式存儲的，它是由存儲這份列表的server共同管理的。假設存儲列表裏的某臺server壞掉了。其它server當即可以替代壞掉的server。並且可以把壞掉的server從列表裏刪除掉，讓故障server退出整個集羣的執行，而這一切的操做又不會由故障的server來操做。而是集羣里正常的server來完畢。

這是一種主動的分佈式數據結構，可以在外部狀況發生變化時候主動改動數據項狀態的數據機構。Zookeeper框架提供了這樣的服務。這樣的服務名字就是：統一命名服務。它和javaEE裏的JNDI服務很是像。

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

　　場景三：配置管理。在分佈式系統裏，咱們會把一個服務應用分別部署到n臺server上，這些server的配置文件是一樣的（好比：我設計的分佈式站點框架裏，服務端就有4臺server，4臺server上的程序都是同樣，配置文件都是同樣），假設配置文件的配置選項發生變化，那麼咱們就得一個個去改這些配置文件。假設咱們需要改的server比較少，這些操做還不是太麻煩，假設咱們分佈式的server特別多，比方某些大型互聯網公司的hadoop集羣有數千臺server。那麼更改配置選項就是一件麻煩而且危急的事情。

這時候zookeeper就可以派上用場了，咱們可以把zookeeper當成一個高可用的配置存儲器，把這種事情交給zookeeper進行管理，咱們將集羣的配置文件複製到zookeeper的文件系統的某個節點上，而後用zookeeper監控所有分佈式系統裏配置文件的狀態，一旦發現有配置文件發生了變化。每臺server都會收到zookeeper的通知，讓每臺server同步zookeeper裏的配置文件，zookeeper服務也會保證同步操做原子性，確保每個server的配置文件都能被正確的更新。

　　場景四：爲分佈式系統提供故障修復的功能。

集羣管理是很是困難的。在分佈式系統裏增長了zookeeper服務，能讓咱們很是easy的對集羣進行管理。集羣管理最麻煩的事情就是節點故障管理，zookeeper可以讓集羣選出一個健康的節點做爲master，master節點會知道當前集羣的每臺server的執行情況，一旦某個節點發生問題，master會把這個狀況通知給集羣其它server，從而又一次分配不一樣節點的計算任務。Zookeeper不只可以發現故障，也會對有故障的server進行甄別，看故障server是什麼樣的故障，假設該故障可以修復，zookeeper可以本身主動修復或者告訴系統管理員錯誤的緣由讓管理員迅速定位問題，修復節點的故障。你們或許還會有個疑問，master故障了，那怎麼辦了？zookeeper也考慮到了這點。zookeeper內部有一個「選舉領導者的算法」，master可以動態選擇，當master故障時候。zookeeper能當即選出新的master對集羣進行管理。

　　如下我要講講zookeeper的特色：

1. zookeeper是一個精簡的文件系統。這點它和hadoop有點像，但是zookeeper這個文件系統是管理小文件的。而hadoop是管理超大文件的。

2. zookeeper提供了豐富的「構件」，這些構件可以實現很是多協調數據結構和協議的操做。好比：分佈式隊列、分佈式鎖以及一組同級節點的「領導者選舉」算法。

3. zookeeper是高可用的，它自己的穩定性是至關之好，分佈式集羣全然可以依賴zookeeper集羣的管理。利用zookeeper避免分佈式系統的單點故障的問題。

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

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

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

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

　　前不久我參加了部門的hadoop興趣小組，測試環境的hadoop、mapreduce、hive及hbase都是我來安裝的，安裝hbase時候安裝要預先安裝zookeeper。最先我是在四臺server上都安裝了zookeeper，但是同事說安裝四臺和安裝三臺是一回事，這是因爲zookeeper要求半數以上的機器可用。zookeeper才幹提供服務。因此3臺的半數以上就是2臺了，4臺的半數以上也是兩臺。所以裝了三臺server全然可以達到4臺server的效果，這個問題說明zookeeper進行安裝的時候一般選擇奇數臺server。

在學習hadoop的過程當中，我感受zookeeper是最難理解的一個子項目。緣由倒不是它技術負責，而是它的應用方向很是讓我困惑，因此我有關hadoop技術第一篇文章就從zookeeper開始。也不講詳細技術實現。而從zookeeper的應用場景講起，理解了zookeeper應用的領域，我想再學習zookeeper就會更加事半功倍。

　　之因此今天要談談zookeeper，也是爲我上一篇文章分佈式站點框架的補充。儘管我設計站點架構是分佈式結構。也作了簡單的故障處理機制，比方：心跳機制，但是對集羣的單點故障仍是沒有辦法的，假設某一臺server壞掉了。client任然會嘗試鏈接這個server。致使部分請求的堵塞。也會致使server資源的浪費。只是我眼下也不想去改動本身的框架，因爲我總認爲在現有的服務上加入zookeeper服務會影響站點的效率，假設有獨立的server集羣部署zookeeper仍是值得考慮的。但是server資源太寶貴了，這個可能性不大。

幸虧咱們部門也發現了這種問題，咱們部門將開發一個強大的遠程調用框架。將集羣管理和通信管理這塊剝離出來，集中式提供高效可用的服務，等部門的遠程框架開發完成。咱們的站點加入新的服務，我想咱們的站點將會更加穩定和高效。