zookeeper

一、zookeeper 是什么

Zookeeper是一個分布式協調服務，可用于服務發現，分布式鎖，分布式領導選舉，配置管理等，這一切的基礎，都是Zookeeper提供了一個類似于Linux檔案系統的樹形結構（可認為是輕量級的記憶體檔案系統，但只適合存少量資訊，完全不適合存盤大量檔案或者大檔案），同時提供了對于每個節點的監控與通知機制，既然是一個檔案系統，就不得不提Zookeeper是如何保證資料的一致性的，

二、zookeeper 集群架構

 Zookeeper集群是一個基于主從復制的高可用集群，通常 Master服務器作為主服務器提供寫服務，其他的 Slave 服務器通過異步復制的方式獲取 Master 服務器最新的資料，并提供讀服務，在 ZooKeeper 中沒有選擇傳統的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色，每個角色承擔如下：

• Leader 一個Zookeeper集群同一時間只會有一個實際作業的Leader，它會發起并維護與各Follwer及Observer間的心跳，所有的寫操作必須要通過Leader完成再由Leader將寫操作廣播給其它服務器，
• Follower 一個Zookeeper集群可能同時存在多個Follower，它會回應Leader的心跳，Follower可直接處理并回傳客戶端的讀請求，同時會將寫請求轉發給Leader處理，并且負責在Leader處理寫請求時，對請求進行投票（“過半寫成功”策略），
• Observer 角色與Follower類似，但是無投票權，

 在集群中zookeeper是如何保證master與slave資料一致性？

為了保證寫操作的一致性與可用性，Zookeeper專門設計了一種名為原子廣播（ZAB）的支持崩潰恢復和訊息廣播的一致性協議，基于該協議，Zookeeper實作了一種主從模式的系統架構來保持集群中各個副本之間的資料一致性，

寫資料時保證一致性：Zookeeper 客戶端會隨機連接到 Zookeeper 集群的一個節點，如果是讀請求，就直接從當前節點中讀取資料；如果是寫請求且當前節點不是leader，那么節點就會向 leader 提交事務，leader 會廣播事務，當leader收到半數的follower反饋后，再向集群中的follower廣播commit訊息，commit就是提交上一步的事務訊息，

服務器運行時期的Leader選舉（當leader宕機后如何選主）？

zookeeper 在集群模式下，leader宕機也不會影響繼續提供服務，但是leader宕機在從新選主程序時無法對外提供服務，會有一個短暫的停頓程序（這里就是與eureka的區別），

• 集群已存在leader時，要加入一臺服務器：對于集群中已經存在Leader而言，此種情況一般都是某臺機器啟動得較晚，在其啟動之前，集群已經在正常作業，對這種情況，該機器試圖去選舉Leader時，會被告知當前服務器的Leader資訊，對于該機器而言，僅僅需要和Leader機器建立起連接，并進行狀態同步即可，
• 集群存在leader宕機需要重新選舉leader：例如server3  宕機了，則剩余的 每個Server發出一個投票，Server1和Server2都會將自己作為Leader服務器來進行投票，每次投票會包含所推舉的服務器的myid和ZXID，使用(myid, ZXID)來表示，此時Server1的投票為(1, 0)，Server2的投票為(2, 0)，然后各自將這個投票發給集群中其他機器，當新的leader選擇出來以后，第二步就是資料同步保證所有的節點與leader資料一致，
• 處理投票，針對每一個投票，服務器都需要將別人的投票和自己的投票進行PK，PK規則如下：優先檢查ZXID，ZXID比較大的服務器優先作為Leader，如果ZXID相同，那么就比較myid，myid較大的服務器作為Leader服務器，

ZXID：實作中Zxid是一個64為的數字，它高32位是epoch用來標識Leader關系是否改變，每次一個Leader被選出來，它都會有一個新的epoch，低32位是個遞增計數，

為什么最好使用奇數臺服務器構成 ZooKeeper 集群？

zookeeper有這樣一個特性：集群中只要有過半的機器是正常作業的，那么整個集群對外就是可用的，也就是說如果有2個zookeeper，那么只要有1個死了zookeeper就不能用了，因為1沒有過半，所以2個zookeeper的死亡容忍度為0；同理，要是有3個zookeeper，一個死了，還剩下2個正常的，過半了（2>3/2），所以3個zookeeper的容忍度為1，如果是4臺zookeeper 如果掛掉2臺， 還剩下2臺 （2 不大于 4/2），顯然不過半所以集群還是不可用，4臺的容忍度還是1，因此不是 不能部署偶數臺，而是偶數臺對于高可用作用不大，浪費服務器，

什么是集群腦裂，zookeeper如何避免腦裂？

集群的腦裂是指，當前集群中存在多個master，例如：當前有三個結點 A1(master)，A2，A3，某一時刻A1與其他結點失去了網路通信，此時A2和A3沒有master所以他們要從新選舉一個master，而A1也是master，即當前集群出現兩個master，

zookeeper如何避免腦裂：當A1結點網路恢復后，他仍然認為自己是leader，這個時候它向其他followers發出寫請求也是會被拒絕的，因為每當新leader產生時，會生成一個epoch，這個epoch是遞增的，followers如果確認了新的leader存在，知道其epoch，就會拒絕epoch小于現任leader epoch的所有請求，那有沒有follower不知道新的leader存在呢，有可能，但肯定不是大多數，否則新leader無法產生，Zookeeper的寫也遵循quorum機制，因此，得不到大多數支持的寫是無效的，舊leader即使各種認為自己是leader，依然沒有什么作用，

三、ZooKeeper 的一些重要概念

ZooKeeper 將資料保存在記憶體中，這也就保證了 高吞吐量和低延遲（但是記憶體限制了能夠存盤的容量不太大，此限制也是保持znode中存盤的資料量較小的進一步原因），

ZooKeeper 是高性能的， 在“讀”多于“寫”的應用程式中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態，（“讀”多于“寫”是協調服務的典型場景，）

會話（Session）

　　Session 指的是 ZooKeeper 服務器與客戶端會話，在 ZooKeeper 中，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接，客戶端啟動的時候，首先會與服務器建立一個 TCP 連接，從第一次連接建立開始，客戶端會話的生命周期也開始了，通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話，也能夠向Zookeeper服務器發送請求并接受回應，同時還能夠通過該連接接收來自服務器的Watch事件通知， Session的sessionTimeout值用來設定一個客戶端會話的超時時間，當由于服務器壓力太大、網路故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在sessionTimeout規定的時間內能夠重新連接上集群中任意一臺服務器，那么之前創建的會話仍然有效，

在為客戶端創建會話之前，服務端首先會為每個客戶端都分配一個sessionID，由于 sessionID 是 Zookeeper 會話的一個重要標識，許多與會話相關的運行機制都是基于這個 sessionID 的，因此，無論是哪臺服務器為客戶端分配的 sessionID，都務必保證全域唯一，

Watcher

　　Watcher（事件監聽器），是Zookeeper中的一個很重要的特性，Zookeeper允許用戶在指定節點上注冊一些Watcher，并且在一些特定事件觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實作分布式協調服務的重要特性，

ACL

Zookeeper采用ACL（AccessControlLists）策略來進行權限控制，類似于 UNIX 檔案系統的權限控制，Zookeeper 定義了如下5種權限

四、zookeeper 的資料結構

ZooKeeper 允許分布式行程通過共享的層次結構命名空間進行相互協調，這與標準檔案系統類似， 名稱空間由 ZooKeeper 中的資料暫存器組成 - 稱為znode，這些類似于檔案和目錄， 與為存盤設計的典型檔案系統不同，ZooKeeper資料保存在記憶體中，這意味著ZooKeeper可以實作高吞吐量和低延遲，

1、PERSISTENT--持久化目錄節點      客戶端與zookeeper斷開連接后，該節點依舊存在

2、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點   客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

3、EPHEMERAL-臨時目錄節點   客戶端與zookeeper斷開連接后，該節點被洗掉

4、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點   客戶端與zookeeper斷開連接后，該節點被洗掉，只是Zookeeper給該節點名稱進行順序編號

五、zookeeper的作用

1、命名服務

在zookeeper的檔案系統里創建一個目錄，即有唯一的path,在我們使用tborg無法確定上游程式的部署機器時即可與下游程式約定好path,通過path即能互相探索發現，

2、配置管理

程式總是需要配置的，如果程式分散部署在多臺機器上，要逐個改變配置就變得困難，好吧，現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然后所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置資訊應用到系統中就好，

 3、集群管理

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

第一點，所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然后監聽父目錄節點的子節點變化訊息，一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被洗掉，所有其他機器都收到通知：某個兄弟目錄被洗掉，于是，所有人都知道他掉線了，新機器加入 也是類似，所有機器收到通知：新兄弟目錄加入，

對于第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為master就好，

4、分布式鎖

• 有了zookeeper的一致性檔案系統，鎖的問題變得容易，鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序，
•  對于第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實作，所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖，用完洗掉掉自己創建的distribute_lock 節點就釋放出鎖，
•  對于第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完洗掉，依次方便，  

標籤：Java

上一篇：什么是“約定大于配置”

下一篇：RocketMQ