從傳統Java Web轉入分布式系統應用，再到接觸分布式協調框架ZooKeeper，通過痛苦的思維邏輯和理念轉變，歷經一個月時間，小伙伴們終于把ZooKeeper嵌入到了BoCloud博云的BeyondContainer中，并在其上進行相應功能的開發： 服務注冊與發現、 集群管理、 模塊的高可用及分布式鎖等。

　　在選定ZooKeeper之前，我們對其他的分布式框架也進行了調研和對比，分別 有etcd和consul。對于etcd而言，在原生接口和提供服務方式方面，etcd更適合作為集群配置服務器，用來存儲集群中的大量數據，方便的REST接口也可以讓集群中的任意一個節點在使用key |value服務時獲取方便，然而etcd在監控服務的狀態和通知方面比較麻煩；consul方面，是使用Go語言開發的分布式協調，對業務發現的管理提供很好的支持，他的HTTP API也能很好的和不同的語言綁定，但在業務檢測方面有一定的延時，不太適合實時響應的情景；并且etcd和consul需要其他組件的配合才能達到ZooKeeper的服務能力，故ZooKeeper則更加的適合于提供分布式協調服務，實現分布式鎖模型方面也較為簡單方便，并且功能全，社區活躍，用戶群體很大，對所有典型的用例都有很好的封裝，支持不同語言的綁定，故最終選定ZooKeeper。

　　在產品開發中使用ZooKeeper是一件有趣的事情，下面就讓我們來詳細扒一扒我們的開發體驗吧。

　　一簡單介紹

　　先來簡單說明下ZooKeeper原理，再來談談在產品中的具體使用。ZooKeeper是一個開放源碼的分布式應用程序協調服務，由知名互聯網公司雅虎創建，是Google Chubby的開源實現。設計目標是為分布式提供一致性服務，其沒有直接采用Paxos算法，而是采用了被稱為ZAB的一致性協議。 ZooKeeper具有以下幾個特征：

　　1、數據模型

　　ZooKeeper使用一個共享的、樹形結構的名字空間-數據模型，其由一系列被稱為ZNode的的數據節點組成，其層級關系，如文件系統的目錄結構一樣，結構如下圖所示：

　　每個Znode上都會保存自己的數據內容以及屬性信息，節點分為持久節點和臨時節點，持久節點除非進行刪除操作，否則將會一直保存在ZooKeeper上；而臨時節點，他的生命周期和客戶端會話綁定，一旦會話失效，這個客戶端所創建的所有臨時節點都會被刪除。另外，可以給節點加上一個屬性：sequential，節點創建的時候，會自動在節點后面追加一個由父節點維護的自增數字。