深刻了解ZooKeeper（二）

　　在上篇博客<< 深刻了解ZooKeeper（一）>>中咱們知道了分佈式協調技術、分佈式鎖的實現和zookeeper服務機制，接下來將進一步瞭解zookeeper究竟能爲咱們作了什麼以及如何去實現的！

1. 內容思惟導圖

2. ZooKeeper提供了什麼？

2.1 設計原則

（1）最終一致性

　　client不論鏈接到哪一個Server，展現給它的都是同一個視圖

（2）可靠性

　　具備簡單、健壯、良好的性能，若是消息messgae被一臺服務器接受，那麼它將被全部的服務器接受

（3）實時性

　　Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。但因爲網絡延時等緣由，Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口

（4）等待無關（wait-free）

　　慢的或者失效的client不得干預快速的client的請求，使得每一個client都能有效的等待

（5）原子性

　　更新智能成功或者失敗，沒有中間狀態

（6）順序性

　　包括全局有序和偏序兩種，全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面

2.2 角色

　　Zookeeper中的角色主要有如下三類，以下表所示：

　　

2.3 文件系統

　　Zookeeper維護一個相似文件系統的數據結構：

　　

　　每一個子目錄都被稱爲znode，和文件系統同樣能夠增長、刪除和修改，惟一不一樣的是znode能夠存儲數據，znode有四種類型：

（1）PERSISTENT-持久化目錄節點

　　客戶端與zookeeper斷開鏈接後，該節點依舊存在

（2） PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點

　　客戶端與zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

（3）EPHEMERAL-臨時目錄節點

　　客戶端與zookeeper斷開鏈接後，該節點被刪除

（4）EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點

　　客戶端與zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

2.4 通知機制

　　客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增長刪除）時，zookeeper會通知客戶端。watch觸發器實現zookeeper的通知機制，關於watch的觸發機制看上篇博客。

2.5 系統模型

　　

3. 咱們用Zookeeper能作什麼？

3.1 命名服務

　　 這個彷佛最簡單，在zookeeper的文件系統裏建立一個目錄，即有惟一的path。在咱們使用tborg沒法肯定上游程序的部署機器時便可與下游程序約定好path，經過path即能互相探索發現，不見不散了。

3.2 配置管理

　　   程序老是須要配置的，若是程序分散部署在多臺機器上，要逐個改變配置就變得困難。好吧，如今把這些配置所有放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，而後全部相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每一個應用程序就會收到 Zookeeper 的通知，而後從 Zookeeper 獲取新的配置信息應用到系統中就好。

　　

3.3 集羣管理

　　所謂集羣管理無在意兩點：是否有機器退出和加入、選舉master

（1）機器退出和加入

　　全部機器約定在父目錄GroupMembers下建立臨時目錄節點，而後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的鏈接斷開，其所建立的臨時目錄節點被刪除，全部其餘機器都收到通知：某個兄弟目錄被刪除，因而，全部人都知道：它上船了。新機器加入 也是相似，全部機器收到通知：新兄弟目錄加入，highcount又有了。

（2）master選舉

　　咱們稍微改變一下，全部機器建立臨時順序編號目錄節點，每次選取編號最小的機器做爲master就好

　　

3.4 分佈式鎖

　　 有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。

（1）保存獨佔

　　咱們將zookeeper上的一個znode看做是一把鎖，經過createznode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。廁全部言：來也沖沖，去也沖沖，用完刪除掉本身建立的distribute_lock 節點就釋放出鎖。

（2）控制時序

　　 /distribute_lock 已經預先存在，全部客戶端在它下面建立臨時順序編號目錄節點，和選master同樣，編號最小的得到鎖，用完刪除，依次進行

　　

3.5 隊列管理

　　兩種類型的隊列：

（1） 同步隊列，當一個隊列的成員都聚齊時，這個隊列纔可用，不然一直等待全部成員到達

　　在約定目錄下建立臨時目錄節點，監聽節點數目是不是咱們要求的數目

（2）隊列按照 FIFO 方式進行入隊和出隊操做

　　和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號

4. Zookeeper如何實現集羣維護一個文件系統的？

4.1 分佈式與數據複製

　　Zookeeper做爲一個集羣提供一致的數據服務，天然，它要在全部機器間作數據複製。

4.1.1 數據複製的好處

（1）容錯

　　一個節點出錯，不致於讓整個系統中止工做，別的節點能夠接管它的工做

（2）提升系統的擴展能力

　　把負載分佈到多個節點上，或者增長節點來提升系統的負載能力

（3）提升性能

　　讓客戶端本地訪問就近的節點，提升用戶訪問速度

4.1.2 數據複製集羣系統分類

　　從客戶端讀寫訪問的透明度來看，數據複製集羣系統分下面兩種：

（1）寫主(WriteMaster)

　　對數據的修改提交給指定的節點。讀無此限制，能夠讀取任何一個節點。這種狀況下客戶端須要對讀與寫進行區別，俗稱讀寫分離

（2）寫任意(Write Any)

　　對數據的修改可提交給任意的節點，跟讀同樣。這種狀況下，客戶端對集羣節點的角色與變化透明　　

　　對zookeeper來講，它採用的方式是寫任意。經過增長機器，它的讀吞吐能力和響應能力擴展性很是好，而寫，隨着機器的增多吞吐能力確定降低（這 也是它創建observer的緣由），而響應能力則取決於具體實現方式，是延遲複製保持最終一致性，仍是當即複製快速響應。咱們關注的重點仍是在如何保證數據在集羣全部機器的一致性，這就涉及到paxos算法。

4.2 數據一致性與paxos算法　

　　聽說Paxos算法的難理解與算法的知名度同樣使人敬仰，因此咱們先看如何保持數據的一致性，這裏有個原則就是：

　　在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。

        Paxos算法解決的什麼問題呢，解決的就是保證每一個節點執行相同的操做序列。好吧，這還不簡單，master維護一個全局寫隊列，全部寫操做都必須 放入這個隊列編號，那麼不管咱們寫多少個節點，只要寫操做是按編號來的，就能保證一致性。沒錯，就是這樣，但是若是master掛了呢。

        Paxos算法經過投票來對寫操做進行全局編號，同一時刻，只有一個寫操做被批准，同時併發的寫操做要去爭取選票，只有得到過半數選票的寫操做纔會被 批准（因此永遠只會有一個寫操做獲得批准），其餘的寫操做競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，全部寫操做都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個編號爲100的寫操做，以後又接受到編號爲99的寫操做（由於網絡延遲等不少不可預見緣由），它立刻能意識到本身 數據不一致了，自動中止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性（總2n+1臺，除非掛掉大於n臺）。