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的特點：
zookeeper是一個精簡的文件系統。zookeeper這個文件系統是管理小文件的。
zookeeper提供了豐富的“構件”，這些構件可以實現很多協調數據結構和協議的操作。例如：分佈式隊列、分佈式鎖以及一組同級節點的“領導者選舉”算法。
zookeeper是高可用的，它本身的穩定性是相當之好，分佈式集羣完全可以依賴zookeeper集羣的管理，利用zookeeper避免分佈式系統的單點故障的問題。
zookeeper採用了鬆耦合的交互模式。這點在zookeeper提供分佈式鎖上表現最爲明顯，zookeeper可以被用作一個約會機制，讓參入的進程不在了解其他進程的(或網絡)的情況下能夠彼此發現並進行交互，參入的各方甚至不必同時存在，只要在zookeeper留下一條消息，在該進程結束後，另外一個進程還可以讀取這條信息，從而解耦了各個節點之間的關係。
zookeeper爲集羣提供了一個共享存儲庫，集羣可以從這裏集中讀寫共享的信息，避免了每個節點的共享操作編程，減輕了分佈式系統的開發難度。
zookeeper的設計採用的是觀察者的設計模式，zookeeper主要是負責存儲和管理大家關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者做出相應的反應，從而實現集羣中類似 Master/Slave 管理模式。
由此可見zookeeper很利於分佈式系統開發，它能讓分佈式系統更加健壯和高效。