zookeeper（動物園管理員），顧名思義，是用來管理hadoop（大象）、hive（蜜蜂）、pig（小豬）的管理員，同時apache hbase、apache solr、linkedin sensei等眾多專案中都採用了zookeeper。
zookeeper曾是hadoop的正式子專案，後發展成為apache頂級專案，與hadoop密切相關但卻沒有任何依賴。它是乙個針對大型應用提供高可用的資料管理、應用程式協調服務的分布式服務框架，基於對paxos演算法的實現，使該框架保證了分布式環境中資料的強一致性，提供的功能包括：配置維護、統一命名服務、狀態同步服務、集群管理等。（原來這個是基於paxos演算法的呀）
在分布式應用中，由於工程師不能很好地使用鎖機制，以及基於訊息的協調機制不適合在某些應用中使用，因此需要有一種可靠的、可擴充套件的、分布式的、可配置的協調機制來統一系統的狀態。zookeeper的目的就在於此。
zookeeper是簡單的：zookeeper的核心是乙個精簡檔案系統，它提供一些簡單的操作和一些額外的抽象操作，例如：排序和通知。
zookeeper是富有表現力的：zookeeper的原語操作是一組構件（building block），可用於實現很多協調資料結構和協議，例如：分布式佇列、分布式鎖和一組同級節點中的leader選舉（leader election）。
zookeeper具有高可用性：zookeeper執行在集群上，被設計成具有較高的可用性，因此應用程式可以完全依賴它。zookeeper可以幫助系統避免出現單點故障，從而構建乙個可靠的應用。
zookeeper採用松耦合互動方式：在zookeeper支援的互動過程中，參與者之間不需要彼此了解。例如：zookeeper可以被用作乙個rendezvous機制，讓程序在不了解其他程序或網路狀況的情況下能夠彼此發現並進行互動。參與協調的各方甚至可以不必同時存在，因為乙個程序在zookeeper中留下一條訊息，在該程序結束後，另外乙個程序還可以讀取這條訊息。
zookeeper是乙個資源庫：zookeeper提供了乙個關於通用協調模式實現和方法的開源共享儲存庫，能使程式設計師免於編寫這類通用的協議。所有人都能夠對這個資源庫進行新增和改進，隨著時間的推移，會使每個人都從中收益。
zookeeper是高效能的：在它的誕生地yahoo!公司，對於以寫為主的工作負載來說，zookeeper的基準吞吐量已超過每秒10000個操作；對於常規的以讀為主的工作負載來說，吞吐量更是高出好幾倍。
理解zookeeper的一種方法是將其看做乙個具有高可用性的檔案系統。但這個檔案系統中沒有檔案和目錄，而是統一使用節點（node）的概念，稱為znode。znode既可以儲存資料（如同檔案），也可以儲存其他znode（如同目錄）。所有的znode構成乙個層次化的資料結構。
persistent nodes：永久有效地節點,除非client顯式的刪除,否則一直存在
ephemeral nodes：臨時節點,僅在建立該節點client保持連線期間有效,一旦連線丟失，zookeeper會自動刪除該節點
sequence nodes：順序節點,client申請建立該節點時，zookeeper會自動在節點路徑末尾新增遞增序號,這種型別是實現分布式鎖,分布式queue等特殊功能的關鍵
索引資訊和集群中機器節點狀態放在zookeeper的一些指定節點，供各個客戶端訂閱使用。
系統日誌（經處理後）儲存，這些日誌通常2-3天後清除。
應用中用到的一些配置資訊集中管理，在應用啟動的時候主動來獲取一次，並在節點上註冊乙個watcher，以後每次配置有更新，實時通知到應用，獲取最新的配置資訊。
業務邏輯中需要用到的一些全域性變數，比如一些訊息中介軟體的訊息佇列通常有個zookeeper，這個offset存放在zk上，這樣集群中每個傳送者都能知道當前的傳送進度。
系統中有些資訊需要動態獲取，並且還會存在人工手動去修改這個資訊。以前通常是暴露出介面，例如jmx介面，有了zookeeper後，只要將這些資訊存放到zookeeper節點上即可。
這個主要是作為分布式命名服務，通過呼叫zookeeper的create node api，能夠很容易建立乙個全域性唯一的path，可以將這個path作為乙個名稱。
zookeeper中特有的watcher註冊於非同步通知機制，能夠很好的實現分布式環境下不同系統之間的通知與協調，實現對資料變更的實時處理。使用方法通常是不同系統都對zookeeper上同乙個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點內容），其中乙個系統update了znode，那麼另乙個系統能夠收到通知，並做出相應處理。使用zookeeper來進行分布式通知和協調能夠大大降低系統之間的耦合。
心跳檢測機制：檢測系統和被測系統之間並不直接關聯起來，而是通過zookeeper上某個節點關聯，大大減少系統耦合。
系統排程模式：某系統有控制台和推送系統兩部分組成，控制台的職責是控制推送系統進行相應的推送工作。管理人員在控制台做的一些操作，實際上是修改了zookeeper上某些節點的狀態，而zk就把這些變化通知給它們註冊watcher的客戶端，即推送系統，於是做出相應的推送任務。
工作匯報模式：一些類似於任務分發系統，子任務啟動後，到zk來註冊乙個臨時節點，並定時將自己的進度進行匯報（將進度寫回這個臨時節點），這樣任務管理者就能夠實時指導任務進度。
分布式鎖，主要得益於zookeeper保證資料的強一致性，即zookeeper集群中任意節點（乙個zookeeper server）上系統znoe的資料一定相同。
鎖服務可以分為兩類：
保持獨佔鎖：所有試圖來獲取這個鎖的客戶端，最終只有乙個可以成功獲得這把鎖。通常的做法是把zookeeper上的乙個znode看做是一把鎖，通過create znode的方式來實現。所有客戶端都去建立/distribute_lock節點，最終成功建立的那個客戶端也即擁有了這把鎖。
控制時序鎖：所有試圖來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全域性時序了。與保持獨佔鎖的做法類似，不同點是/distribute_lock已經預先存在，客戶端在它下面建立臨時有序節點（可以通過節點控制屬性控制：createmode.ephemeral_sequential來指定）。zookeeper的父節點(/distribute_lock)維持乙份sequence，保證子節點建立的時序性，從而形成每個客戶端的全域性時序。
master選舉：在分布式環境中，相同的業務應用分布在不同的機器上，有些業務邏輯（例如一些耗時的計算、網路i/o處理），往往需要讓整個集群中的某一台機器進行執行，其餘機器可以共享這個結果，這樣可以減少重複勞動、提高效能。利用zookeeper的強一致性，能夠保證在分布式高併發情況下節點建立的全域性唯一性，即：同時有多個客戶端請求建立/currentmaster節點，最終一定只有乙個客戶端請求能夠建立成功。利用這個特性，就能很輕易的在分布式環境中進行集群選取了。另外，這種場景演化一下，就是動態master選舉。這就要用到 ephemeral_sequential型別節點的特性了。上文中提到，所有客戶端建立請求，最終只有乙個能夠建立成功。在這裡稍微變化下，就是允許所有請求都能夠建立成功，但是得有個建立順序，於是所有的請求最終在zk上建立結果的一種可能情況是這樣： /currentmaster/-1、/currentmaster/-2、/currentmaster/-3……。每次選取序列號最小的那個機器作為master，如果這個機器掛了，由於他建立的節點會馬上消失，那麼之後最小的那個機器就是master了。
master選舉的容災措施是，可以隨時進行手動指定master，就是說應用在zookeeper在無法獲取master資訊時，可以通過比如http方式，向乙個地方獲取master。
佇列方面，有兩種方式：一種是常規的先進先出佇列，另一種是要等到佇列成員聚齊之後的才統一按序執行。
對於先進先出佇列，和分布式鎖服務中的控制時序場景基本原理一致，這裡不再贅述。
第二種佇列其實是在fifo佇列的基礎上作了乙個增強。通常可以在/queue這個znode下預先建立乙個/queue/num節點，並且賦值為n（或者直接給/queue賦值n），表示佇列大小，之後每次有佇列成員加入後，就判斷下是否已經到達佇列大小，決定是否可以開始執行了。這種用法的典型場景是，分布式環境中，乙個大任務task a，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中乙個子任務完成（就緒），那麼就去/tasklist下建立自己的臨時時序節點（createmode.ephemeral_sequential），當/tasklist發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。
rendezvous 會合
分布式服務框架 Zookeeper
createmode persistent 建立後只要不刪就永久存在 ephemeral 會話結束年結點自動被刪除，ephemeral結點不允許有子節點 sequential 節點名末尾會自動追加乙個10位數的單調遞增的序號，同乙個節點的所有子節點序號是單調遞增的 persistent sequen...
大型分布式服務框架
1 首先遠端服務呼叫有三種模式 同步 非同步 future 非同步 callback 三種呼叫模型,正常的都是同步呼叫，呼叫的時候阻塞當前執行緒，非同步一般只會在特殊的情景下有用。2 全域性配置 所有服務的配置應該是需要在乙個全域性配置中心配置 zookeeper集群 的，而不是寫死在 裡面，避免出...
微服務 分布式服務框架
spring cloud rest與rpc比較 dubbo 和 spring cloud 對比 通訊協議 傳輸的格式都屬於協議 服務路由 分布式服務上線時都是集群組網部署，集群中會存在某個服務的多例項，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分布式服務框架需要能夠滿足...