在前面的兩篇中，我們介紹了zookeeper的安裝與簡單的使用，這一篇我們就來看一下zookeeper的一些基本原理。

一、什麼是zookeeper

zookeeper是什麼？開啟百度，輸入zookeeper，我們可以看到是這麼定義的：

ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。

看了這一段話，每一句都有不認識的東西，像我這樣的小青年內心就是：

剛上來就是分散式，那麼什麼是分散式？什麼是叢集？瞭解了這些才能進一步去了解之後的東西。在此期間我在網上也是看了許多講解什麼是分散式，有一個解釋比較簡單易懂，大意是這樣的：

你開了一家飯店，請了一位廚師，廚師負責洗菜、做菜、端菜，後來客人多了廚師忙不過來，又請了兩位廚師，這樣就有了三位廚師來共同完成，這就是叢集的概念。後來為了提高
效率與質量，你又分別請了三個洗菜工，三個端菜員，將原先整體屬於廚師的任務分割開，讓廚師專心做菜。這種將原先屬於一個角色的任務分割給不同的角色，各司其職，這就是分散式。

簡單概括的話：分散式就是將一個業務拆分為多個業務，放在不同的伺服器上。

二、為什麼使用zookeeper

在以前的專案中，如果專案簡單的話，那麼一臺伺服器就可以搞定了，但是當專案越來越複雜，請求多了，服務也多了，這時候就需要採用分散式了。

但是採用分散式也存在一些問題，我們將專案部署在多臺伺服器上，如果想要修改某些配置資訊，就需要逐個去通知伺服器，再逐個修改。而且在分散式情況下，對於鎖資源的獲取、資料的儲存也是有著一些問題存在的。

通過使用zookeeper，可以實現諸如分散式應用配置管理、統一命名服務、狀態同步服務、叢集管理等功能。

zookeeper也可以擔任註冊中心，在dubbo中有個架構圖：

在dubbo的這個場景中，zookeeper就可以作為註冊中心(Resgistry)。服務的提供者將服務註冊到zookeeper，服務消費者在使用的時候直接去註冊中心去檢視服務使用即可。倒是類似於中介，提供者與消費者有事找註冊中心就行，後續的操作交給zookeeper。此外，zookeeper也是dubbo官方推薦的註冊中心。

三、zookeeper的一些重要概念&&資訊

高可用：

在公司的專案中，zookeeper是以叢集的形式搭建的，採用叢集搭建的好處就在於如果某個時刻突然出現了意外，掛了個一臺伺服器，只要剩餘存活的伺服器超過了原先的半數，那麼zookeeper是還可以正常提供服務的。

來看下zookeeper的架構圖就明白了：

它的伺服器之間是相互連線的，即使其中一臺掛了，客戶端也可以連線其它的伺服器。至於連線的是哪個伺服器，這個就是視情況而定了。

zookeeper的特點：

1、順序一致性：當一個客戶端發起多個請求，這些請求會按照發起的順序被zookeeper執行。
2、原子性：原子性這個東西我們大家都不陌生，畢竟在資料庫中是見過這個東西的。在zookeeper中也是同樣的意思。因為zookeeper基本採用叢集的方式搭建的，那麼向zookeeper中寫資料的時候，要麼所有的伺服器都寫入，要麼所有的伺服器都不寫入。
3、單一系統映像：zookeeper叢集雖然有多臺伺服器，但是無論客戶端連線的是哪臺伺服器，最終看到的資料模型是要一樣的。
4、可靠性：一旦客戶端發起的請求被應用，那麼更改的結果就會被持久化，直到下次被覆蓋。

節點

在分散式中，節點一般代表伺服器。但是在zookeeper中，節點除了代表伺服器，還代表了zookeeper中的儲存節點。關於節點znode的一些資訊，在我的上一篇文章 zookeeper的使用與基本原理(一) 有介紹過，此外還有一些關於zookeeper的監視器(watcher)、許可權(ACL)也都在上篇文章有提到。

叢集角色：

在zookeeper中，伺服器節點有三種角色：跟隨者(follower)、領導者(leader)、觀察者(observer)。


在zookeeper中就是這個樣子的，至於觀察者，是需要配置才有的。

領導者：負責進行投票的發起與進行，更新系統狀態。

跟隨者：負責與客戶端進行通訊，客戶端發起讀操作的話，可以立即執行，如果發起寫操作，那麼需要將寫操作的資訊傳遞給領導者。同時跟隨者可以在領導者選舉的過程中進行投票。

觀察者：觀察者雖然是observer，但是它並不邊緣ob。它與跟隨者唯一的區別就是觀察者不會在領導者選舉的時候投票。此外，跟隨者與觀察者都可以歸類於學習者。

伺服器節點的三種狀態：

LOOKING：當前伺服器不知道領導者是誰，正在尋找領導者。
LEADING：當前伺服器節點為領導者
FOLLOWING：表示當前狀態為跟隨者。

四、ZAB協議

ZAB（ZooKeeper Atomic Broadcast 原子廣播）協議是為分散式協調服務 ZooKeeper 專門設計的一種支援崩潰恢復的原子廣播協議，它是zookeeper的核心。在zookeeper中，通過ZAB協議來實現分散式資料一致性。基於此協議，zookeeper實現了一種主備模式的系統架構來保證叢集中各個伺服器節點的資料一致性。

ZAB協議包含兩部分：恢復模式（選主）、廣播模式（同步）。

恢復模式：恢復模式有兩個應用場景：一個是在叢集啟動時，這個時候所有伺服器剛剛啟動，需要選舉出領導者。另一種就是當領導者伺服器掛掉了，此時其餘的伺服器處於LOOKING狀態，需要選舉出新的領導者。那麼這個領導者怎麼選舉出呢？

啟動時：第一臺伺服器server1啟動的時候，因為只有它一個伺服器，所以沒辦法進行領導者的選舉，當第二臺伺服器server2啟動的時候，此時兩臺伺服器之間可以相互通訊，此時進入leader選舉過程。

1、每臺伺服器發出一次投票，server1與server2都會設定自己為領導者（好像現實中也是這樣啊。。。）。每次投票會帶出兩個引數：(myid，zxid)，myid在之前zookeeper配置的時候就說過了，假設設定server1的myid為1，server2的myid為2，zxid則是當時的事務id。此時server1為(1，0)，server2為(2,0)。
2、叢集中的每臺伺服器接收來自叢集中其它伺服器的投票資訊
3、票已經投完了，那麼就開始進行領導者選舉的PK。首先比較的是zxid，誰的zxid大，那麼誰就是領導者。如果zxid一樣，那麼就比較myid，誰的myid大，誰就是領導者。此時server2的zxid與server1的zxid相同，但是server2的myid大於server1的myid，所以server2勝出，server2獲得了兩票勝出，而server1PK失敗，就需要更改自己為(2，0)去進行接下來的選舉。
4、假設有三臺伺服器，此時為(2,0)的已經有兩臺伺服器了，雖然第三臺為(3,0)，但是第二臺伺服器的得票數已經超過了半數，理應當選為領導者。
5、一旦確認了領導者，那麼每個伺服器就會更新自己的狀態，領導者更改為LEADING、跟隨者更改為FOLLOWING狀態。

執行時領導者選舉：

在zookeeper叢集使用的時候，如果出現了leader當機的情況，那麼肯定是要選舉出一個leader來繼續下面的工作。其實與啟動時領導者選舉是類似的，跟隨者發出自己的myid與zxid進行互相PK，但是此時zookeeper已經工作過一段時間了，它的zxid可能不像開始的時候為0，但是選舉的思想還是先比較zxid，誰的zxid大，誰就是領導者。zxid相同就比較myid。

廣播模式：
ZAB廣播模式是通過類似兩階段提交協議的方式解決資料一致性。

1、領導者收到客戶端的寫請求。
2、領導者生成一個新的事務，併為這個事務生成一個唯一的ZXID。
3、領導者將這個事務提議(propose)傳送給所有的跟隨者(follower)節點。
4、跟隨者節點將收到的事務請求加入到歷史佇列(history queue)中，併傳送ack給領導者。
5、當領導者收到半數以上的跟隨者的ack訊息，領導者就會傳送commit請求。
6、當跟隨者收到commit請求時，從歷史佇列中將事務請求commit。

五、zookeeper叢集為什麼要奇數臺伺服器

其實在上面的ZAB協議中就可以看到，zookeeper叢集的執行只要半數以上的伺服器節點能夠執行就OK了。我們假設叢集A有三臺伺服器，叢集B有四臺伺服器，根據我們在上面瞭解的，叢集A允許一臺伺服器當機之後還可以完好執行。而叢集B也只能允許一臺伺服器當機，如果叢集B有兩臺伺服器當機了，那麼剩下的伺服器就不滿足zookeeper叢集的正常執行的條件了。所以從這方面看，三臺伺服器叢集與四臺伺服器叢集的容錯數量是一樣的，但是部署三臺伺服器相比於四臺伺服器，會更減少資源的消耗。