原文：https://blog.csdn.net/qq_18416057/article/details/54927189
zookeeper，有些聽說過，有些人沒有，本人也是因爲自己在做一個分佈式的系統，由dubbo+zookeeper整合，所以接觸一下。到底是什麼東西？關於這個問題我首先到其官網和百度百科。其大致就是zookepper是hadoop的一個子項目，Apache軟件基金會下的一個項目，作爲分佈式協調作用的，作用類型與我們的大腦。而至於hadoop是什麼的話，我只能告訴你，是一個大數據的框架，具體是什麼，小的不清楚，哈哈。其實zookeeper在hadoop的作用，我可以再打個比喻。不管是hadoop還是其它分佈式系統，就好比我們人的身體，有心臟，胃，有呼吸道系統。腿，手。。。。。等等。這麼多的子系統處於分佈式環境，怎麼協調呢？那就是我們大腦（zookeeper），大家可以把zookeepr想成大腦，本身沒有其它功能，只有負責協調，聯絡子系統的功能，具體有哪些協調功能，往下看
回到主題，zookeeper官網是這麼介紹它的
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
中文翻譯
ZooKeeper是一個集中式服務，用於維護配置信息，命名，提供分佈式同步和提供組服務。所有這些類型的服務以分佈式應用程序的某種形式或另一種形式使用。每次他們被實現，有很多工作，以修復錯誤和競爭條件是不可避免的。由於實現這些服務的難度，應用程序最初通常嘲弄它們，這使得它們在變化的存在下變得脆弱並且難以管理。即使正確地完成，這些服務的不同實施導致在應用被部署時的管理複雜性。
其實zookeeper怎麼協調hadoop以及其它的分佈式系統的，我們可以從其介紹看出（標紅色部分），下面針對以上4個，我們簡單講一下，目的就是大家能簡單知道，瞭解zookeeper。
1、維護配置信息
這個的應用場景：
比方說你有20多個，甚至更多的項目，共同使用很多配置文件。當你要修改配置文件時，你是不是要一個個去複製一遍，這樣很耗時間，精力，而且也不利於管理。而且現在項目都是分佈式項目，在加上如果項目已經上線，那你如果一個個去改，然後重啓服務，那不是麻煩死了。
zookeeper提供的這個配置管理，就是把這公用的配置文件提取出來放到一個地方，對這個地方（目錄節點）進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中就好，項目不需要重啓，這樣上面一開始講的問題就解決了.
參考文章：http://www.jianshu.com/p/01388f06e75d
2、命名
命名功能其實在dubbo上體現的，相信大家都知道jndi吧，如果不知道的話那我也沒有辦法了。zookeeper的命名服務跟jndi功能幾乎差不多，這樣說大家應該大致應該知道zookeeper的命名功能了。如果用過duboo+zookeeper整合的系統的人也能知道，正是因爲這個命名服務，才方便了分佈式個個項目之間的聯繫.在SOA框架裏面，RMI框架就是通過很簡單的你要某個服務器上的URL來獲取遠方服務器上的對象來調用服務，但到集羣，和分佈式環境下，如何做到子項目之間調用的關係不會很複雜，不會到時候出現問題都不知道哪個服務調用的哪個，所以這裏就需要一個服務器專門替我們管理這裏服務的信息和調節，管理這些服務，讓我們可以把集中與項目的業務，zookeeper的命名功能就是這麼一個服務器。當集羣的時候，相同的一個服務有很多個提供者，這些提供者啓動時，提供者服務器的相關信息，包括服務接口，地址，端口等一下連接提供者的信息註冊到zookper中，當消費者要消費某服務的時候，從zookeeper中拿改服務的所有提供者信息目錄，再根據dubbo的負載均衡機制從地圖中選擇一個提供者。其實從作用1,2可以看出，zookeeper大家可以看出是一個文件系統（類似與linux文件系統），還是那句話，zookeeper就是分佈式中充當大腦。
3、分佈式同步
分佈式的同步，又叫分佈式鎖。相信對於鎖這個概念，大家都應該知道吧。對於單服務器的鎖，大家都知道怎麼做。在分佈式上，如果A要調用B的方法C，C方法也要加鎖，但這個鎖不能想單服務器那樣加，因爲這個是分佈式調用的方法，不一樣。就像事務一樣，單服務器上的事務和分佈式事務不一樣。zookeeper提供了一個分佈式同步（鎖）的方法，使用其提供的，客戶可以省了很多事。
zookeeper分佈式鎖的思路
有了清晰的思路之後, 還需要補充一些細節. 進程如何知道thisPath是所有子節點中最小的呢? 可以在創建的時候, 通過getChildren方法獲取子節點列表, 然後在列表中找到排名比thisPath前1位的節點, 稱爲waitPath, 然後在waitPath上註冊監聽, 當waitPath被刪除後, 進程獲得通知, 此時說明該進程獲得了鎖.
大致流程圖
參考文獻
https://my.oschina.net/91jason/blog/500503
四、提供組服務
其實這個組服務也就是集羣管理了，就像dubbo+zookeeer。服務器上的服務註冊，或者獲取服務，都是在zookeeper上操作的，所以所謂的提供組服務也就包括創建組、加入組成員、列出組成員和刪除組成員。對於這些服務，主要通過zookeeper心跳機制，它會去檢測與其連接的一些服務器的數量，以及信息。什麼時候連上zookeeper，或什麼時候斷開都有其心跳機制完成。