分佈式鎖服務ZooKeeper

ZooKeeper的安裝和配置：

下載ZooKeeper

解壓：tar -xzvf  zookeeper-3.4.3.tar.gz  

在conf目錄下建立一個配置文件zoo.cfg，tickTime=2000
dataDir=/opt/zookeeper/data
dataLogDir=/opt/zookeeper/dataLog         clientPort=2181

啓動ZooKeeper的Server：sh bin/zkServer.sh start, 若是想要關閉，輸入：zkServer.sh stop 

建立myid文件，server1機器的內容爲：1，server2機器的內容爲：2，server3機器的內容爲：3

在conf目錄下建立一個配置文件zoo.cfg，tickTime=2000
dataDir=/opt/zookeeper/data
dataLogDir=/opt/zookeeper/dataLog        

clientPort=2181           

initLimit=5        

syncLimit=2            

server.1=server1:2888:3888                  

server.2=server2:2888:3888                

server.3=server3:2888:3888

ZooKeeper的角色：

領導者（leader），負責進行投票的發起和決議，更新系統狀態 

學習者（learner），包括跟隨者（follower）和觀察者（observer），follower用於接受客戶端請求並想客戶端返回結果，在選主過程當中參與投票 

Observer能夠接受客戶端鏈接，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是爲了擴展系統，提升讀取速度 

客戶端（client），請求發起方

ZooKeeper的工做原理：

Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和server具備相同的系統狀態。

一旦leader已經和多數的follower進行了狀態同步後，他就能夠開始廣播消息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啓動，發現leader，並和leader進行狀態同步。待到同步結束，它也參與消息廣播。Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分的followers支持。

廣播模式須要保證proposal被按順序處理，所以zk採用了遞增的事務id號(zxid)來保證。全部的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的server都恢復到一個正確的狀態。

leader選舉

每一個Server啓動之後都詢問其它的Server它要投票給誰？

對於其餘server的詢問，server每次根據本身的狀態都回複本身推薦的leader的id和上一次處理事務的zxid（系統啓動時每一個server都會推薦本身）

收到全部Server回覆之後，就計算出zxid最大的哪一個Server，並將這個Server相關信息設置成下一次要投票的Server。

計算這過程當中得到票數最多的的sever爲獲勝者，若是獲勝者的票數超過半數，則改server被選爲leader。不然，繼續這個過程，直到leader被選舉出來。

leader就會開始等待server鏈接 

Follower鏈接leader，將最大的zxid發送給leader 

Leader根據follower的zxid肯定同步點 

完成同步後通知follower 已經成爲uptodate狀態 

Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了。

 

Zookeeper