詳解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