詳解Zookeeper原理與應用場景

Zookeeper 分佈式協調服務

應用之處：發佈、訂閱，命名服務，分佈式協調和分佈式鎖

對比 Chubby：

Chubby 被定義爲 分佈式的鎖服務

爲分佈式系統提供 鬆耦合、粗粒度 的分佈式鎖功能

其由兩部分組成

提供數據的讀寫接口並管理相關配置數據的服務端

另外一部分是客戶端使用的 SDK

爲對外提供穩定服務，每個 Chubby 單元都由一組服務器組成，使用共識算法從集羣中選舉出主節點

實現原理：

文件系統：

Zookeeper 也使用文件系統組織系統中存儲的資源

• /parent

• /parent/node1

• /parent/node2

• /parent/node3

其並無文件和文件夾的概念，只有 Znode 概念，它既能夠做爲容器存儲數據，也能夠持有其餘 Znode 造成父子關係

Znode 有四種類型：

1. PERSISTENT：持久

2. persistent_sequential：持久且有序

3. ephemeral：臨時

4. ephemeral_sequential：臨時且有序

臨時節點：

客戶端鏈接 Z 時纔會保持存在的節點，當客戶端和服務端鏈接中斷，則當前鏈接持有的全部節點都會被刪除

持久節點：

與臨時節點相反，不會隨會話鏈接的中斷而刪除，須要客戶端主動刪除

順序性：

若是使用 Z 的順序節點，那麼全部節點就會在名字的末尾附加一個序列號，序列號是由父節點維護的單調遞增計數器生成

臨時/持續節點：

 

通知實現原理：

實現分佈式排他鎖：

第一種，經過建立臨時 Znode 簡單實現：

第二種，經過建立臨時順序 Znode 實現：

 

第三種，解決第二種的羊羣效應：

1. 客戶端鏈接 Zookeeper，並在 /lock 下建立臨時且有序（即EPHEMERAL_SEQUENTIAL）的子節點，如，第一個子節點爲 /lock/lock-000，第二個爲 /lock/lock-001，以此類推；

2. 建立成功後，獲取 /lock 下的子節點列表，判斷剛建立的子節點在列表中是不是序號最小的子節點，若是是，則認爲是得到鎖，不然，監聽剛建立的子節點的前一位子節點的刪除消息，等得到該子節點的變動通知後，重複此步驟，直至得到鎖爲止；

3. 執行業務代碼；

4. 完成業務代碼後，刪除對應子節點釋放鎖；

與 Redis 實現分佈式鎖比較：

1. Redis 須要本身實現重試邏輯，比較消耗性能；

2. zk 重試獲取鎖，對節點註冊監聽器便可，不須要主動嘗試，性能開銷小；

3. 若是 Redis 獲取鎖的客戶端掛了，就不能主動刪除 key，只能等待 key 的超時到期，而 zk 會主動發現客戶端斷連，並將臨時 znode 刪除，觸發後面的監聽器邏輯

參考

實現分佈式共享鎖：

 

擴展：

DNS：

• DNS（Domain Name System，域名系統），萬維網上做爲域名和 IP 地址相互映射的一個分佈式數據庫，方便用戶訪問互聯網，無需記住可以被機器直接讀取的 IP 數串。

• 經過域名，最終獲得該域名對應的 IP 地址的過程叫作域名解析。

• DNS 協議運行在 UDP 協議智商，使用端口號 53。

共識算法：

Raft

參考

https://draveness.me/zookeeper-chubby