zookeeper介紹
zookeeper是一個為分布式應用提供一致性服務的軟件，它是開源的Hadoop項目中的一個子項目，并且根據google發表的論文來實現的，接下來我們首先來安裝使用下這個軟件，然后再來探索下其中比較重要一致性算法。

zookeeper安裝和使用
zookeeper的安裝基本上可以按照 http://hadoop.apache.org/zookeeper/docs/current/ zookeeperStarted.html 這個頁面上的步驟完成安裝，這里主要介紹下部署一個集群的步驟，因為這個官方頁面似乎講得并不是非常詳細(Running Replicated Zookeeper)。

由于手頭機器不足，所以在一臺機器上部署了3個server,如果你手頭也比較緊，也可以這么做。那么我建了3個文件夾，如下
server1 server2 server3

然后每個文件夾里面解壓一個zookeeper的下載包，并且還建了幾個文件夾，總體結構如下,最后那個是下載過來壓縮包的解壓文件
data dataLog logs zookeeper-3.3.2

那么首先進入data目錄，創建一個myid的文件，里面寫入一個數字，比如我這個是server1,那么就寫一個1，server2對應myid文件就寫入2，server3對應myid文件就寫個3

然后進入zookeeper-3.3.2/conf目錄，那么如果是剛下過來，會有3個文件，configuration.xml, log4j.properties,zoo_sample.cfg,這3個文件我們首先要做的就是在這個目錄創建一個zoo.cfg的配置文件，當然你可以把zoo_sample.cfg文件改成zoo.cfg，配置的內容如下所示：

tickTime=2000
initLimit=5
syncLimit=2
dataDir=xxxx/zookeeper/server1/data
dataLogDir=xxx/zookeeper/server1/dataLog
clientPort=2181
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

標紅的幾個配置應該官網講得很清楚了，只是需要注意的是clientPort這個端口如果你是在1臺機器上部署多個server,那么每臺機器都要不同的clientPort，比如我server1是2181,server2是2182，server3是2183，dataDir和dataLogDir也需要區分下。

最后幾行唯一需要注意的地方就是 server.X 這個數字就是對應 data/myid中的數字。你在3個server的myid文件中分別寫入了1，2，3，那么每個server中的zoo.cfg都配server.1,server.2,server.3就OK了。因為在同一臺機器上，后面連著的2個端口3個server都不要一樣，否則端口沖突，其中第一個端口用來集群成員的信息交換，第二個端口是在leader掛掉時專門用來進行選舉leader所用。

進入zookeeper-3.3.2/bin 目錄中，./zkServer.sh start啟動一個server,這時會報大量錯誤？其實沒什么關系，因為現在集群只起了1臺server，zookeeper服務器端起來會根據zoo.cfg的服務器列表發起選舉leader的請求，因為連不上其他機器而報錯，那么當我們起第二個zookeeper實例后，leader將會被選出，從而一致性服務開始可以使用，這是因為3臺機器只要有2臺可用就可以選出leader并且對外提供服務(2n+1臺機器，可以容n臺機器掛掉)。

接下來就可以使用了，我們可以先通過 zookeeper自帶的客戶端交互程序來簡單感受下zookeeper到底做一些什么事情。進入zookeeper-3.3.2/bin（3個server中任意一個）下，./zkCli.sh –server 127.0.0.1:2182,我連的是開著2182端口的機器。

?

說明一下:myid 這個文件是沒有擴展名的,分布啟動后的效果

那么，首先我們隨便打個命令，因為zookeeper不認識，他會給出命令的help,如下圖

ls(查看當前節點數據),
ls2(查看當前節點數據并能看到更新次數等數據) ,
create(創建一個節點) ,
get(得到一個節點，包含數據和更新次數等數據),
set(修改節點)
delete(刪除一個節點)

通過上述命令實踐，我們可以發現，zookeeper使用了一個類似文件系統的樹結構，數據可以掛在某個節點上，可以對這個節點進行刪改。另外我們還發現，當改動一個節點的時候，集群中活著的機器都會更新到一致的數據。

zookeeper的數據模型
在簡單使用了zookeeper之后，我們發現其數據模型有些像操作系統的文件結構，結構如下圖所示

(1) 每個節點在zookeeper中叫做znode,并且其有一個唯一的路徑標識，如/SERVER2節點的標識就為/APP3/SERVER2
(2) Znode可以有子znode，并且znode里可以存數據，但是EPHEMERAL類型的節點不能有子節點
(3) Znode中的數據可以有多個版本，比如某一個路徑下存有多個數據版本，那么查詢這個路徑下的數據就需要帶上版本。
(4) znode 可以是臨時節點，一旦創建這個 znode 的客戶端與服務器失去聯系，這個 znode 也將自動刪除，Zookeeper 的客戶端和服務器通信采用長連接方式，每個客戶端和 服務器通過心跳來保持連接，這個連接狀態稱為 session，如果 znode 是臨時節點，這個 session 失效，znode 也就刪除了
(5) znode 的目錄名可以自動編號，如 App1 已經存在，再創建的話，將會自動命名為 App2
(6) znode 可以被監控，包括這個目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化可以通知設置監控的客戶端，這個功能是zookeeper對于應用最重要的特性，通過這個特性可以實現的功能包括配置的集中管理，集群管理，分布式鎖等等。

通過java代碼使用zookeeper
Zookeeper的使用主要是通過創建其jar包下的Zookeeper實例，并且調用其接口方法進行的，主要的操作就是對znode的增刪改操作，監聽znode的變化以及處理。

以下為主要的API使用和解釋

Zookeeper的主流應用場景實現思路 除去官方示例）

(1)配置管理
集中式的配置管理在應用集群中是非常常見的，一般商業公司內部都會實現一套集中的配置管理中心，應對不同的應用集群對于共享各自配置的需求，并且在配置變更時能夠通知到集群中的每一個機器。

Zookeeper很容易實現這種集中式的配置管理，比如將APP1的所有配置配置到/APP1 znode下，APP1所有機器一啟動就對/APP1這個節點進行監控(zk.exist(“/APP1″,true)),并且實現回調方法Watcher，那么在zookeeper上/APP1 znode節點下數據發生變化的時候，每個機器都會收到通知，Watcher方法將會被執行，那么應用再取下數據即可(zk.getData(“/APP1″,false,null));

以上這個例子只是簡單的粗顆粒度配置監控，細顆粒度的數據可以進行分層級監控，這一切都是可以設計和控制的。
(2)集群管理
應用集群中，我們常常需要讓每一個機器知道集群中（或依賴的其他某一個集群）哪些機器是活著的，并且在集群機器因為宕機，網絡斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器。

Zookeeper同樣很容易實現這個功能，比如我在zookeeper服務器端有一個znode叫/APP1SERVERS,那么集群中每一個機器啟動的時候都去這個節點下創建一個EPHEMERAL類型的節點，比如server1創建/APP1SERVERS/SERVER1(可以使用ip,保證不重復)，server2創建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS這個父節點，那么也就是這個父節點下數據或者子節點變化都會通知對該節點進行watch的客戶端。因為EPHEMERAL類型節點有一個很重要的特性，就是客戶端和服務器端連接斷掉或者session過期就會使節點消失，那么在某一個機器掛掉或者斷鏈的時候，其對應的節點就會消失，然后集群中所有對/APP1SERVERS進行watch的客戶端都會收到通知，然后取得最新列表即可。

另外有一個應用場景就是集群選master,一旦master掛掉能夠馬上能從slave中選出一個master,實現步驟和前者一樣，只是機器在啟動的時候在APP1SERVERS創建的節點類型變為EPHEMERAL_SEQUENTIAL類型，這樣每個節點會自動被編號，例如

打印結果：[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]

打印結果:[testChildPath2, testChildPath1, testChildPath4, testChildPath3]

我們默認規定編號最小的為master,所以當我們對/APP1SERVERS節點做監控的時候，得到服務器列表，只要所有集群機器邏輯認為最小編號節點為master，那么master就被選出，而這個master宕機的時候，相應的znode會消失，然后新的服務器列表就被推送到客戶端，然后每個節點邏輯認為最小編號節點為master，這樣就做到動態master選舉。

淺析
　創建連接：
　　1.獲取服務主機列表
　　2.設置超時時間
　　3.注冊客戶端事件
　　4.以線程安全的方式創建請求連接（啟動客戶端請求隊列，循環隊列基于socket通信、根據請求類型執行不同的請求動作）
　　請求流程：
　　構造請求頭、構造request,reponse、構造響應頭、構造Packet對象,packet對象準備好后，把整個對象放入一個outgoingQueue?
packet被放入outgoingQueue中，等待SendThread把packet對應的內容發送給server。server處理分3步在doio方法中ReadLength ReadConnectResult ReadResponse，直到ReadResponse方法中確定packet請求結束。
響應流程：
　　針對心跳的ping請求的resp，針對auth請求的resp，一般接口請求的resp，如果接口請求要求了watcher，當watcher關注的內容有變化時的notification
鎖相關部分API方法：
　　創建節點： create
　　demo：zk.Create(Dir, severname.GetBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.Persistent);
　　其中CreateMode分為4類Persistent、PersistentSequential、Ephemeral、EphemeralSequential
　　PERSISTENT 創建持久化節點，對應機器關閉連接后節點/數據不會消失
　　PERSISTENT_SEQUENTIAL 如果PATH是以’/’結尾則以這個PATH作為父節點，創建一個子節點，其子節點名字是一個按先后順序排列的數值；否則創建一個名字是‘/’后面字符加上先后順序排列的數值字符串的節點，同樣創建持久節點
　　EPHEMERAL 創建瞬時節點，Zookeeper在感知連接機器宕機后會清除它創建的瞬時節點
　　EPHEMERAL_SEQUENTIAL 穿件瞬時順序節點，和PERSISTENT_SEQUENTIAL一樣，區別在于它是瞬時的
　　刪除節點 delete
　　demo ：zk.Delete(Dir, -1);
　　前一個參數代表節點名稱（一般用作路徑），后一個是版本號 -1表示全匹配
　　查看節點 exists
　　demo ： zk.Exists(Dir, new MyWatch2());
　　獲取數據 getData?
　　demo ：zk.GetData(Dir, new MyWatch2(), stat);
　　獲取一個節點的數據，可注入watcher 　　
　　設置數據 setData?
　　demo ： zk.SetData(Dir, new byte[1], 1);
　　獲取下級節點集合 GetChildren
　　demo ：zk.GetChildren(Dir, true);
存儲
　　znodes類似文件和目錄。但它不是一個典型的文件系統，zookeeper數據保存在內存中，這意味著zookeeper可以實現高吞吐量和低延遲。
watcher
　　Zookeeper有兩種watches，一種是data watches，另一種是child watches。其中，getData()和exists()以及create()等會添加data watches，getChildren()會添加child watches。而delete()涉及到刪除數據和子節點，會同時觸發data watches和child watches。
???? 詳細可以參考： http://www.geminikwok.com/2011/09/08/%E6%B5%85%E8%B0%88zookeeper-watch%E4%BA%8B%E4%BB%B6/
算法
　　Paoxs算法 本篇中僅用單臺server做demo 改個時間詳細介紹下Paoxs　　

總結

我們初步使用了一下zookeeper并且嘗試著描述了幾種應用場景的具體實現思路，接下來的文章，我們會嘗試著去探究一下zookeeper的高可用性與leaderElection算法。

參考： http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

http://hadoop.apache.org/zookeeper/docs/current/

http://rdc.taobao.com/team/jm/archives/448

zookeeper windows安裝和使用