文章目錄
- 概念
- 架構圖
- 資料模型和分層命名空間
- 特性
- 節點
- 集群
- paxos
- ZAB 協議
- watch
- 分布式鎖
概念
分布式應用程式的分布式協調服務，基于公開的簡單原語可以實作更高級別的同步、配置維護、組和命名服務，
架構圖
一主多從，更新資料首先更新到主節點，在同步到從節點，可在任意節點讀取資料
資料模型和分層命名空間
ZooKeeper 提供的命名空間很像標準檔案系統，名稱由斜桿（/）分隔的一系列路徑元素，每個節點都由路徑標識，與為存盤而設計的典型檔案系統不同，ZooKeeper資料保存在記憶體中
特性
- 順序一致性 - 來自客戶端的更新將按照它們的順序應用
- 原子性 - 更新成功或者失敗，沒有部分結果，
- 統一視圖 - 無論客戶端連接到哪個服務器，都將看到相同的視圖
- 可靠性 - 應用一旦更新，它將持續到客戶端覆寫更新
- 及時性 - 系統的客戶視圖保證在一定時間范圍是最新的
節點
- 持久節點（有序、無序）
- 臨時節點（有序、無序）
- 節點存盤
Zxid(64位) = epoch（32位） + 事務ID（32位）
cZxid -> 創建的IDmZxid -> 修改的ID
PZxid -> 當前目錄下最大的創建ID
ephemeralOwner -> 臨時節點下存盤的session
集群
- 集群搭建
service.id（myid） = ip：port（通信埠）：port（選舉埠） - 集群角色
leader 處理事務請求
follower 處理讀請求，轉發事物請求，參與選舉投票
observice 不參與選舉投票的follower，協助follower處理更多的客戶端請求 - 集群事務
基于改進版的2PC，半數通過則提交
paxos
基于訊息傳遞的一致性演算法
paxos決議
ZAB 協議
Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議
-
崩潰恢復模式 - 選舉Leader + 恢復資料
照成原因
（1）leader 失去過半節點的聯系
（2）leader 掛了
投票機制
每次投票傳入（myid，zxid，epoch）
myid 服務器id
Zxid(64位) = epoch（32位） + 事務ID（32位）
epoch 朝代，每次選舉后 + 1
（1）優先檢查zxid，越大優先為leader
（2）zxid相同，比較myid大小，越大優先為leader -
訊息廣播模式 - 資料同步
2pc + 佇列 + 多數成功
watch
客戶端先向Zookeeper服務端成功注冊想要監聽的節點狀態，同時客戶端本地會存盤該監聽器相關的資訊在WatchManager中，當Zookeeper服務端監聽的資料狀態發生變化時，Zookeeper就會主動通知發送相應事件資訊給相關會話客戶端，客戶端就會在本地回應式的回呼相關Watch的Handler，
分布式鎖
臨時順序節點 + watch，最小的獲取鎖，后面的節點watch前一個節點，一旦最小的釋放了鎖，只給第二個節點發事件回呼
官方網站
漫畫：如何用Zookeeper實作分布式鎖？
漫畫：什么是ZooKeeper？
思維導圖地址
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/438661.html
標籤：其他
上一篇：Likely root cause: java.nio.file.NoSuchFileException: /usr/local/es/plugins/ik/plugin-descriptor（踩坑）
下一篇：Hadoop生態系統（二）