ZooKeeper技術內幕-系統模型

系統模型數組

  • 數據模型
    • ZooKeeper視圖機構和標準Unix 文件系統很是類似,使用了數據節點(ZNode)
    • ZNode是ZooKeeper數據的最小單元
    • ZNode能夠掛在子節點,保存數據信息
    • ZNode層次化,樹結構存儲

  • 在ZooKeeper中,事務操做指的是能改變ZooKeeper服務器狀態的操做
    • 包括數據節點的建立、刪除、數據內容修改、客戶端會話的建立和失效
    • 每個事務請求,ZooKeeper爲其分配全局惟一id:zxid

節點特性安全

  • 在ZooKeeper中,數據節點可分爲:持久節點(PERSISTENT)、臨時節點(EPHEMERAL)、順序節點(SEQUENTIAL)三大類,四種組合
    • PERSISTENT
    • PERSISTENT_SEQUENTIAL(順序節點被建立時,節點名一個數字後綴,數字後綴最大值是最大整數)
    • EPHEMERAL(臨時節點不能建立子節點)
    • EPHEMERAL_SEQUENTIAL
  • 狀態信息
    •  

版本--保證分佈式數據原子性操做服務器

  • ZooKeeper爲數據節點引入版本信息的概念

  • ZooKeeper版本的概念是指:對數據節點內容、子節點列表、節點ACL信息的修改次數
  • ZooKeeper的 version屬性正是用來實現樂觀鎖的 「寫入校驗」
    • setDataRequest 方法中檢查版本號
    • 若是version ==-1 表明忽略檢查

悲觀鎖(悲觀併發控制):網絡

  • 一種很是嚴格的併發控制策略
  • 具備強烈的獨佔性和排他性,可以有效地避免不一樣事務對同一數據併發更新而形成形成的數據一致性問題
  • 悲觀鎖適合解決那些對於數據更新競爭很是激烈的場景
  • 簡單粗暴的解決併發控制問題
  • 從頭至尾加鎖,假定數據併發操做必定會相互干擾

樂觀鎖(樂觀併發控制):併發

  • 常見併發控制策略
  • 比較寬鬆友好
  • 假定不少事務不會相互干擾,可是也存在相互影響的可能,
  • 在提交前進行檢查,若是已經被修改,所有回滾
  • 數據讀取,寫入校驗,數據寫入三個階段
    • jdk CAS是最典型的樂觀鎖,全稱爲Compare-And-Swap

Watcher----數據變動的通知運維

  • Watcher 接口
    • 表示一個標準的事件處理器,定義了事件通知相關的邏輯
    • 包含 KeeperState(通知狀態)、EventType(事件類型) 倆枚舉類
    • 事件回調方法 process(WatchedEvent event);

Watcher 事件分佈式

  • 相同事件類型,在不一樣通知狀態表明含義不一樣

  • NodeDataChanged 事件
    • 不管數據內容、數據版本號變化,都會觸發
    • 由於只要客戶調用數據更新接口,就會改變版本號,哪怕內容沒變
  • NodeChildrenChanged 事件
    • 子節點列表變化:子節點個數組成狀況的變動
    • 內容變化不會觸發
  • AuthFailed 事件
    • 如下面倆程序爲例:
      • 第一個會拋出NoAuthException
      • 第二個拋出AuthFailedException,同時受到對應的事件通知(AuthFailed,None)

  • 回調函數 process()
    • 當ZooKeeper向客戶端發送Watcher事件通知時,客戶端就會對相應的process方法進行回調
    • WatchedEvent 和 WatcherEvent
      • 兩者描述的都是服務端事件
      • WatchedEvent 是一個邏輯封裝,服務端和客戶端執行過程當中所需的邏輯對象
      • WatcherEvent 實現了序列化接口,進行傳輸的封裝
      • 服務端生成WatchedEvent 以後,會對其進行封裝成WatcherEvent 傳輸到客戶端
      • 客戶端拿到WatcherEvent傳遞給process方法,還原成WatchedEvent
  • 事件封裝都及其簡單,好比:ZNode 數據內容變動事件
    • 客戶端只能收到簡單信息:
    • 客戶端沒法獲取到更新後的新數據,須要客戶端再次主動請求獲取,這是Watcher機制很是重要的特性
  • 工做機制:
    • 包括三個部分:客戶端註冊、服務端處理、客戶端回調

客戶端註冊Watcher:函數

  • getData、getChildren、exist三個方法可向ZooKeeper註冊Watcher
  • getData爲例:
    • 註冊後,客戶端首先會對請求request 進行標記(「使用Watcher監聽」),同時會封裝一個Watcher的註冊信息WatcherRegistration
      • WatcherRegistration用於暫時保存數據節點的路徑Watcher對應關係
  • ZooKeeper中最小的通訊協議單元是 Packet
    • 客戶端和服務端的任何網絡傳輸都須要封裝成Packet對象
    • 在客戶端中WatcherRegistration會被封裝到packet對象,
    • 而後放入發送隊列,等待客戶端發送
    • 而後,客戶端回想服務端發送請求,同時等待回覆
    • 完成請求發送後,會有客戶端SendThread線程的 readResponse 負責接收服務端響應
  • finishPacket會從Packet中取出Watcher 註冊到 ZKWatchManager
  • register方法中會將暫時保存在WatcherRegistration 的Watcher 對象轉交給 ZKWatchManager 的 dataWatchers
    • dataWatchers是 Map 類型,用於將數據節點的路徑和Watcher對象一一對應

  • 客戶端每調用一次getData,就會註冊一個Watcher,這些Watcher實體都會被傳輸到服務端嗎?
    • 不是,都傳的話服務端內存確定吃不消
    • WatchRegistration 封裝如Packet 進行傳輸,並非對對象進行徹底序列化
    • 以下源碼,只將requestHeader、request兩個屬性進行序列化
    • WatchRegistration 並無序列化到底層字節數組中,不會進行網絡傳輸

服務端處理Watcher線程

  • 客戶端不會將Watcher 真正傳遞給服務端,服務端是如何完成註冊呢?
    • FinalRequestProcessor 裏的processRequest 判斷是否須要註冊
    • getData中的 getWatch方法 判斷是否須要註冊
    • 傳入 ServerCnxn 接口實例(表明客戶端和服務端鏈接接口
      • 默認是 NIOServerCnxn,也可引入Netty,NettyServerCnxn
      • 數據節點路徑和ServerCnxn被存入WatchManager 的 watchTables、watch2Paths
      • WatchManager 還負責事件觸發,移除已經觸發的事件
    • DataTree 會託管兩個 WatchManager:dataWatches、childWatches

Watcher觸發3d

  • NodeDataChanged事件觸發條件是:watcher 監聽的數據節點數據內容變動
    • process 實際調用的是:
      • 服務端 watcher本質保存的是 ServerCnxn
      • process方法邏輯很是簡單,不是客戶端的真正邏輯,僅僅是向客戶端發送一個事件通知

客戶端回調watcher

  • SendThread 接收事件通知
    • XID 是 -1 表明是一個通知類型的響應
    • 四個步驟:
      1. 反序列化,從response 中拿到WatcherEvent
      2. 處理 chrootPath,生成相關中間路徑
      3. 還原 WatchedEvent,將WatcherEvent 轉換成WatchedEvent
      4. 回調 Watcher ,最後將WatchedEvent 交給 eventThread(在下一輪中進行Watcher 回調)
  • EventThread 處理事件通知:
    • 專門用來處理服務端事件通知的線程
    • queueEvent方法
    • 從 ClientWatchManager 取出全部相關watchers
  • 獲取到相關watcher,放入waitingEvents 隊列
    • 待處理watcher 隊列
    • EventThread 的run() 方法會不斷處理該隊列

ACL---保障數據的安全

  • ACL(Access control list):訪問控制列表
    • 細粒度
  • 如何保障ZooKeeper 誤操做帶來的數據隨意變動
  • UGO(user group others)權限控制機制
    • 粗粒度權限控制機制
  • 包含內容:
    • 權限模式(Scheme):
      • ip模式:
        • ip:168.192.10.3
        • 表示權限控制針對該ip
      • Digest模式
        • 相似:用戶名:密碼
      • world 模式
        • 最開放,全部用戶不須要權限校驗均可使用
      • super
        • 超級用戶,能夠對ZooKeeper任何節點進行任何操做
        • 運維人員清理垃圾數據
    • 受權對象(id):
    • 權限(Permission):
      • 被容許的操做

權限擴展體系

註冊權限控制器

  • 兩種方式:
    • 系統屬性
    • 文件配置
相關文章
相關標籤/搜索