zookeeper的使用(五)--系統模型
一、前言
前面已經講解了Zookeeper的一些應用場景,但是並沒有深入到Zookeeper內部進行分析,本篇將講解其系統模型。
二、系統模型
2.1 資料模型
Zookeeper的資料節點稱為ZNode,ZNode是Zookeeper中資料的最小單元,每個ZNode都可以儲存資料,同時還可以掛載子節點,因此構成了一個層次化的名稱空間,稱為樹。
在Zookeeper中,事務是指能夠改變Zookeeper伺服器狀態的操作,一般包括節點建立與刪除,資料節點內容更新和客戶端會話建立與失效,對於每個事務請求,Zookeeper都會為其分配一個全域性唯一的事務ID,用ZXID表示,通常是64位的數字,每個ZXID對應一次更新操作,從這些ZXID中可以間接地識別出Zookeeper處理這些更新操作請求的全域性順序。
2.2 節點特性
在Zookeeper中,每個資料節點都是由生命週期的,型別不同則會不同的生命週期,節點型別可以分為持久節點(PERSISTENT)、臨時節點(EPHEMERAL)、順序節點(SEQUENTIAL)三大類,可以通過組合生成如下四種型別節點
1. 持久節點(PERSISTENT)。節點建立後便一直存在於Zookeeper伺服器上,直到有刪除操作來主動清楚該節點。
2. 持久順序節點(PERSISTENT_SEQUENTIAL)。相比持久節點,其新增了順序特性,每個父節點都會為它的第一級子節點維護一份順序,用於記錄每個子節點建立的先後順序。在建立節點時,會自動新增一個數字字尾,作為新的節點名,該數字字尾的上限是整形的最大值。
3. 臨時節點(EPEMERAL)。臨時節點的生命週期與客戶端會話繫結,客戶端失效,節點會被自動清理。同時,Zookeeper規定不能基於臨時節點來建立子節點,即臨時節點只能作為葉子節點。
4. 臨時順序節點(EPEMERAL_SEQUENTIAL)。在臨時節點的基礎新增了順序特性。
每個節點除了儲存資料外,還儲存了節點本身的一些狀態資訊,可通過get命令獲取。
2.3 版本--保證分散式資料原子性操作
每個資料節點都具有三種型別的版本資訊,對資料節點的任何更新操作都會引起版本號的變化。
version-- 當前資料節點資料內容的版本號
cversion-- 當前資料子節點的版本號
aversion-- 當前資料節點ACL變更版本號
上述各版本號都是表示修改次數,如version為1表示對資料節點的內容變更了一次。即使前後兩次變更並沒有改變資料內容,version的值仍然會改變。version可以用於寫入驗證,類似於CAS。
2.4 Watcher--資料變更通知
Zookeeper使用Watcher機制實現分散式資料的釋出/訂閱功能。
Zookeeper的Watcher機制主要包括客戶端執行緒、客戶端WatcherManager、Zookeeper伺服器三部分。客戶端在向Zookeeper伺服器註冊的同時,會將Watcher物件儲存在客戶端的WatcherManager當中。當Zookeeper伺服器觸發Watcher事件後,會向客戶端傳送通知,客戶端執行緒從WatcherManager中取出對應的Watcher物件來執行回撥邏輯。
2.5 ACL--保障資料的安全
Zookeeper內部儲存了分散式系統執行時狀態的後設資料,這些後設資料會直接影響基於Zookeeper進行構造的分散式系統的執行狀態,如何保障系統中資料的安全,從而避免因誤操作而帶來的資料隨意變更而導致的資料庫異常十分重要,Zookeeper提供了一套完善的ACL許可權控制機制來保障資料的安全。
我們可以從三個方面來理解ACL機制:許可權模式(Scheme)、授權物件(ID)、許可權(Permission),通常使用"scheme:id:permission"來標識一個有效的ACL資訊。
許可權模式用來確定許可權驗證過程中使用的檢驗策略,有如下四種模式:
1. IP,通過IP地址粒度來進行許可權控制,如"ip:192.168.0.110"表示許可權控制針對該IP地址,同時IP模式可以支援按照網段方式進行配置,如"ip:192.168.0.1/24"表示針對192.168.0.*這個網段進行許可權控制。
2. Digest,使用"username:password"形式的許可權標識來進行許可權配置,便於區分不同應用來進行許可權控制。Zookeeper會對其進行SHA-1加密和BASE64編碼。
3. World,最為開放的許可權控制模式,資料節點的訪問許可權對所有使用者開放。
4. Super,超級使用者,是一種特殊的Digest模式,超級使用者可以對任意Zookeeper上的資料節點進行任何操作。
授權物件是指許可權賦予的使用者或一個指定實體,如IP地址或機器等。不同的許可權模式通常有不同的授權物件。
許可權是指通過許可權檢查可以被允許執行的操作,Zookeeper對所有資料的操作許可權分為CREATE(節點建立許可權)、DELETE(節點刪除許可權)、READ(節點讀取許可權)、WRITE(節點更新許可權)、ADMIN(節點管理許可權)。
三、總結
本篇部落格介紹了Zookeeper中的系統模型,系統模型的五個部分是Zookeeper提供一系列服務的基礎,之後筆者會結合原始碼進行相應分析。謝謝各位園友觀看~
相關文章
- 搭建分散式系統的利器:ZooKeeper分散式
- 五種傳統IO模型模型
- ZooKeeper的系統列印Log的處理方法
- 學習五:zooKeeper的安裝配置
- 銷售使用CRM系統整合Excel的五個技巧Excel
- IT系統的業務模型分析與系統建模模型
- Zookeeper 在Linux系統上的安裝,並且啟動zookeeper服務Linux
- 分散式系統:系統模型分散式模型
- 系統學習iOS動畫之五:使用UIViewPropertyAnimatoriOS動畫UIView
- THINKPHP5 模型使用歷程(五)PHP模型
- 支付系統設計:支付系統的賬戶模型模型
- Linux系統運維筆記(五) 使用者的操作Linux運維筆記
- zookeeper使用教程
- zookeeper的原理和使用(一)
- [譯] 使用 Go 和 ReactJS 構建聊天系統 (五)GoReactJS
- 推薦系統召回四模型之全能的FM模型模型
- ZooKeeper分散式專題(二) -- zookeeper應用場景及資料模型分散式模型
- 真實案例:使用LLM大模型及BERT模型實現合同審查系統大模型
- 基於ZooKeeper,Spring設計實現的引數系統Spring
- 使用 Go 和 ReactJS 構建聊天系統(五):改善前端GoReactJS前端
- 《推薦系統》-DIN模型模型
- 《推薦系統》-PNN模型模型
- BOSS系統三戶模型模型
- ZooKeeper 使用 Java APIJavaAPI
- 五個模型整合模型
- Linux(五)——檔案系統Linux
- Laravel 第五章學習——使用者模型Laravel模型
- CRM系統中銷售漏斗的五步
- 五大CRM系統的重要功能
- 全面降低windows系統的安全隱患(五)Windows
- linux(五) 檔案系統的內部Linux
- 基於開源模型搭建實時人臉識別系統(五):人臉跟蹤模型
- 作業系統—I/O 模型作業系統模型
- 選擇合適的推薦系統模型模型
- 多租戶系統的核心概念模型模型
- 檔案系統(五):exFAT 檔案系統原理詳解
- zookeeper學習02 使用
- zookeeper使用和原理探究