zookeeper技術淺析

Zookeeper是hadoop的一個子項目，雖然源自hadoop，但是我發現zookeeper脫離hadoop的範疇開發分布式架構的運用越來越多。今天我想談談zookeeper，本文不談如何使用zookeeper，而是zookeeper到底有哪些實際的運用，哪些類型的應用能發揮zookeeper的優勢，最後談談zookeeper對分布式網站架構能産生怎樣的作用。

　　Zookeeper是針對大型分布式系統的高可靠的協調系統。由這個定義我們知道zookeeper是個協調系統，作用的對象是分布式系統。為什麼分布式系統需要一個協調系統了？理由如下：

　　開發分布式系統是件很困難的事情，其中的困難主要展現在分布式系統的“部分失敗”。“部分失敗”是指資訊在網絡的兩個節點之間傳送時候，如果網絡出了故障，發送者無法知道接收者是否收到了這個資訊，而且這種故障的原因很複雜，接收者可能在出現網絡錯誤之前已經收到了資訊，也可能沒有收到，又或接收者的程序死掉了。發送者能夠獲得真實情況的唯一辦法就是重新連接配接到接收者，詢問接收者錯誤的原因，這就是分布式系統開發裡的“部分失敗”問題。

　　Zookeeper就是解決分布式系統“部分失敗”的架構。Zookeeper不是讓分布式系統避免“部分失敗”問題，而是讓分布式系統當碰到部分失敗時候，可以正确的處理此類的問題，讓分布式系統能正常的運作。

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

　　場景一：有一組伺服器向用戶端提供某種服務（例如：我前面做的分布式網站的服務端，就是由四台伺服器組成的叢集，向前端叢集提供服務），我們希望用戶端每次請求服務端都可以找到服務端叢集中某一台伺服器，這樣服務端就可以向用戶端提供用戶端所需的服務。對于這種場景，我們的程式中一定有一份這組伺服器的清單，每次用戶端請求時候，都是從這份清單裡讀取這份伺服器清單。那麼這分清單顯然不能存儲在一台單節點的伺服器上，否則這個節點挂掉了，整個叢集都會發生故障，我們希望這份清單時高可用的。高可用的解決方案是：這份清單是分布式存儲的，它是由存儲這份清單的伺服器共同管理的，如果存儲清單裡的某台伺服器壞掉了，其他伺服器馬上可以替代壞掉的伺服器，并且可以把壞掉的伺服器從清單裡删除掉，讓故障伺服器退出整個叢集的運作，而這一切的操作又不會由故障的伺服器來操作，而是叢集裡正常的伺服器來完成。這是一種主動的分布式資料結構，能夠在外部情況發生變化時候主動修改資料項狀态的資料機構。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的特點：

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，最早我是在四台伺服器上都安裝了zookeeper，但是同僚說安裝四台和安裝三台是一回事，這是因為zookeeper要求半數以上的機器可用，zookeeper才能提供服務，是以3台的半數以上就是2台了，4台的半數以上也是兩台，是以裝了三台伺服器完全可以達到4台伺服器的效果，這個問題說明zookeeper進行安裝的時候通常選擇奇數台伺服器。在學習hadoop的過程中，我感覺zookeeper是最難了解的一個子項目，原因倒不是它技術負責，而是它的應用方向很讓我困惑，是以我有關hadoop技術第一篇文章就從zookeeper開始，也不講具體技術實作，而從zookeeper的應用場景講起，了解了zookeeper應用的領域，我想再學習zookeeper就會更加事半功倍。

　　之是以今天要談談zookeeper，也是為我上一篇文章分布式網站架構的補充。雖然我設計網站架構是分布式結構，也做了簡單的故障處理機制，比如：心跳機制，但是對叢集的單點故障還是沒有辦法的，如果某一台伺服器壞掉了，用戶端任然會嘗試連接配接這個伺服器，導緻部分請求的阻塞，也會導緻伺服器資源的浪費。不過我目前也不想去修改自己的架構，因為我總覺得在現有的服務上添加zookeeper服務會影響網站的效率，如果有獨立的伺服器叢集部署zookeeper還是值得考慮的，但是伺服器資源太寶貴了，這個可能性不大。幸好我們部門也發現了這樣的問題，我們部門将開發一個強大的遠端調用架構，将叢集管理和通訊管理這塊剝離出來，集中式提供高效可用的服務，等部門的遠端架構開發完畢，我們的網站加入新的服務，我想我們的網站将會更加穩定和高效。