作者：陳葉皓（攜程郵輪研發部軟件架構師）
是不是要在標題的“作用”之前加上“重要”兩個字，我猶豫了一下，zookeeper提供的功能是如此的重要，以至於如果你在應用中不使用它，早晚也會在你的應用中去實現zookeeper 的功能，所以，zookeeper值得你花（一點）時間去掌握。
zookeeper是為了“分布式”而誕生的，我反復在說“分布式”，並不是趕潮流，而是被潮流推着向前。在任何互聯網生產應用中，哪怕你的公司規模小，訪問量用一台服務器足夠應付，仍然不能容忍當服務器故障時，沒有備用的服務器可切換，這個稱為“防止單點故障”，因為你至少要用兩台服務器來防止單點故障，所以你已經在“分布式”的服務環境里。
我們來回顧上一篇提到的“為什么要在服務層設計讀寫分離”，我把應用層的通用服務分為“讀”服務和“寫”服務，“讀”服務用集群來實現高可用高性能，而“寫”服務用單台服務器來保證事務順序執行。
那么，“單台服務器”聽上去好危險的樣子，於是今天的主角登場，我們需要zookeeper。
你也許聽到過，這種應用場景叫做master/slave，或者我更喜歡稱為主/備模式，在這種場景下，我有兩台服務器（主和備），任何情況下，只有“主”在工作，“備”是在主出現故障時，接替“主”來提供服務。在zookeeper的支持下，這一過程是這樣實現的，
Zookeeper提供目錄和節點的服務，當我的兩台服務器啟動時，會在zookeeper的指定目錄下創建對應自己的臨時節點（這個過程稱為“注冊”），所謂臨時節點，是靠心跳（定時向zookeeper服務器發送數據包）維系，當服務器出現故障（無法向zookeeper服務器發送數據包），zookeeper會刪除臨時節點。服務器向zookeeper注冊時，zookeeper會分配序列號，我們認為序列號小的那個，就是“主”，序列號大的那個，就是“備”。
當我們的客戶端（通常是web server）需要訪問“寫”服務時，需要連接zookeeper，獲得指定目錄下的臨時節點列表，也就是已經注冊的服務器信息，獲得序列號小的那台“主”服務器的地址，進行后續的訪問操作。以達到“總是訪問主服務器”的目的。
當“主”服務器發生故障，zookeeper從指定目錄下刪除對應的臨時節點，同時可以通知關心這一變化的所有客戶端，高效且迅速的傳播這一信息，你想一想，如果不是使用zookeeper，要自己實現這個功能，可沒。。。那么簡單（不許唱！）
我們為了消除單點故障而使用的主/備模式依賴zookeeper，那么zookeeper可不能有單點故障，所以zookeeper在誕生的時候，就是用集群的模式工作，用多台服務器來消除自身的單點故障隱患，怎么樣，無可挑剔吧。
總結，在多核並行計算模式下，我認定基於消息傳遞的actor模型（源自erlang）是正確的編程方式，在actor模型下，可以簡單實現基於服務層的串行操作，保證“寫”操作的完整和一致。使用actor模型，需要用主/備的部署架構來消除單點故障，實現主/備的部署架構，最簡單可靠的方法是使用zookeeper。所以我現在的軟件架構是這么推導出來的高並發需求 -> 異步計算 (使用actor model) -> master/slave (使用zookeeper)
原文鏈接：http://techshow.ctrip.com/archives/788.html