天天看點
傳回

Zookeeper 入門第一篇

轉載原文位址：
  1. ZooKeeper學習總結 第一篇：ZooKeeper快速入門
  2. ZooKeeper學習總結 第二篇：ZooKeeper深入探讨
  3. ZooKeeper學習第一期---Zookeeper簡單介紹

1. 概述

Zookeeper簡單來說就是一個分布式協調技術的具體實作，所謂分布式協調技術就是在叢集環境下，協調叢集中多台機器并發通路控制，實作臨界資源加鎖和有序通路，防止造成“髒資料”的後果。是以Zookeeper最常見的應用就是：分布式鎖。除此之外，基于Zookeerper提供的其他特性，還産生了更豐富的應用：配置資訊維護、分組服務、分布式消息隊列、分布式通知/協調等。

前面提到了那麼多的服務，比如分布式鎖、配置維護、組服務等，那它們是如何實作的呢，我相信這才是大家關心的東西。ZooKeeper在實作這些服務時，首先它設計一種新的資料結構——Znode，然後在該資料結構的基礎上定義了一些原語，也就是一些關于該資料結構的一些操作。有了這些資料結構和原語還不夠，因為我們的ZooKeeper是工作在一個分布式的環境下，我們的服務是通過消息以網絡的形式發送給我們的分布式應用程式，是以還需要一個通知機制——Watcher機制。那麼總結一下，ZooKeeper所提供的服務主要是通過：資料結構+原語+watcher機制，三個部分來實作的。
原語：原語 作業系統或計算機網絡用語範疇。是由若幹條指令組成的，用于完成一定功能的一個過程。primitive or atomic action 是由若幹個機器指令構成的完成某種特定功能的一段程式，具有不可分割性·即原語的執行必須是連續的，在執行過程中不允許被中斷。

Zookeeper資料模型

Zookeeper資料模型Znode

Zookeeper擁有一個樹形的層級結構，這和标準的檔案系統非常相似，下圖所示：

Zookeeper 入門第一篇

從圖中我們可以看出Zookeeper的資料模型，在結構上和标準檔案系統非常相似，都是采用了這種樹形層次結構，Zookeeper樹中的每個節點被稱為——Znode。和檔案系統的目錄樹一樣，Zookeeper樹中的每個節點可以擁有子節點。下面是Znode的特點：

  • Znode結構：

    Zookeeper命名空間中的Znode，兼具檔案(存儲)和目錄兩種特點。既像檔案一樣維護着資料、元資訊、ACL、時間戳等資料結構，又像目錄一樣可以作為路徑辨別的一部分。圖中的每個節點稱為一個Znode。每個Znode由3個部分組成：

  1. stat：此為狀态資訊, 描述該Znode的版本, 權限等資訊
  2. data：與該Znode關聯的資料
  3. children：該Znode下的子節點

  • 隻适合存儲小資料

    ZooKeeper雖然可以關聯一些資料，但并沒有被設計為正常的資料庫或者大資料存儲，相反的是，它用來管理排程資料，比如分布式應用中的配置檔案資訊、狀态資訊、彙集位置等等。這些資料的共同特性就是它們都是很小的資料，通常以KB為大小機關。ZooKeeper的伺服器和用戶端都被設計為嚴格檢查并限制每個Znode的資料大小至多1M，但正常使用中應該遠小于此值。總而言之，Zookeeper是被設計用來協調服務的，znode隻适合存儲小資料

  • Znode路徑：

    Znode通過路徑引用，如同Unix中的檔案路徑。但路徑必須是絕對的，不能使用

    ../

     這種相對路徑，是以路徑開頭都必須是斜杠來開頭，也就是從根路徑

    /

     開始。除此之外，他們必須是唯一的，也就是說每一個路徑隻有一個表示，是以這些路徑不能改變(但不是資料不能改變)。在Zookeeper中，路徑由Unicode字元串組成，并且有一些限制。字元串“/zookeeper”用以儲存管理資訊。比如關鍵配置資訊。

  • Znode的資料通路

    Znode資料讀寫是原子的，也就是說讀操作将擷取與節點相關的所有資料，寫操作也将替換掉節點的所有資料。另外，每一個節點都擁有自己的ACL(通路控制清單)，這個清單規定了使用者的權限，即限定了特定使用者對目标節點可以執行的操作。

  • Znode的節點類型

    Zookeeper中的節點有兩種，分别為臨時節點和永久節點。節點的類型在建立時即被确定，并且不能改變。

  1. 臨時節點(EPHEMERAL)：該節點的生命周期僅限于建立它的用戶端和服務端之間的連接配接沒有斷開，用戶端斷開連接配接後，Znode将會被删除。雖然每個臨時的Znode都會綁定到一個用戶端會話，但它們對所有的用戶端還是可見的。另外，Zookeeper的臨時節點不允許擁有子節點。
  2. 永久節點(PERSISTENT)：該節點的生命周期不依賴于用戶端會話，并且隻有在用戶端顯示執行删除操作的時候，它們才能被删除。
  3. 順序節點：當建立Znode的時候，使用者可以設定讓Zookeeper自動在路徑結尾添加一個遞增的計數。這個計數值是由一個單調遞增的計數器來生成的，且對此節點的父節點來說是唯一的，它的格式為“%10d”(10位數字，沒有數值的數位用0補充)，例如，建立節點時傳入的path是“/aa”，建立後的則可能是“/aa0000000002"。

      總結上面， Znode的節點類型有：永久(PERSISTENT)、永久順序(PERSISTENT_SEQUENTIAL)、臨時(EPHEMERAL)、臨時順序(EPHEMERAL_SEQUENTIAL) ，參見：

org.apache.zookeeper.CreateMode

  • 螢幕(Watch)

    用戶端可以在節點上設定螢幕(watch)。當節點狀态發生改變時（Znode的增删改）将會觸發watch所對應的操作。當watch被觸發時，Zookeeper将會向用戶端發送且僅發送一條通知，因為watch常常隻能被觸發一次。後面，将對此塊知識點展開叙述。

Zookeeper中的時間

Zookeeper有多種記錄時間的形式，其中包含以下幾個重要屬性：

  • Zxid

    緻使Zookeeper節點狀态改變的每一個操作都将使節點接收到一個Zxid格式的時間戳，并且這個時間戳全局有序。也就是說，每個對節點的改變都将産生一個唯一的Zxid。如果Zxid1的值小于Zxid2的值，那麼Zxid1所對應的事件發生在Zxid2所對應的事件之前。實際上，Zookeeper的每個節點維護着三個Zxid值，分别為：cZxid、mZxid、PZxid。

  1. cZxid：是節點的建立時間所對應的Zxid格式時間戳。

  2. mZxid：是節點的修改時間所對應的Zxid格式時間戳。

    實作中Zxid是一個64位的數字，它高32位是epoch(翻譯：時期;紀元;世;新時代)用來辨別leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。

  • 版本号

    對節點的每一個操作都将緻使這個節點的版本号增加。每個節點維護這三個版本号，它們分别為：

  1. version: 節點資料版本号
  2. cversion：子節點版本号
  3. aversion：節點所擁有的ACL版本号

總結 --> Zookeeper節點的主要屬性

一個節點擁有的表示其狀态的主要屬性如下圖所示：

Znode節點屬性結構

Zookeeper 入門第一篇

ACL(節點通路權限控制)

ACL(即：Access Control List) 通路權限控制清單，Zookeeper就是通過ACL機制來實作對Znode節點的權限控制，Znode在建立時可以帶有一個ACL清單。 我們可以從三個方面了解ACL機制，分别是：權限模式(Scheme 權限驗證過程中使用的檢驗政策)、授權對象(ID 權限将要被賦予的對象 )和權限(Permission 權限清單)，通常使用“scheme : id : permission”來辨別一個有效的ACL資訊。

權限模式：Scheme

  • IP

    Ip模式通過IP位址粒度來進行權限控制，例如配置了“ip:192.168.0.110”，即表示權限控制都是針對于這個IP位址的。同時，IP模式也支援按照網段的方式來進行配置，例如“ip:192.168.0.1/24”表示針對于192.168.0.*這種IP段進行權限控制。

  • Digest

    使用者名+密碼的形式進行驗證

  • World

    無任何權限校驗，所有使用者都可以在不進行任何權限校驗的情況下操作Zookeeper上的資料。另外，World模式也可以看作是一個特殊的Digest模式，它隻有一個權限辨別，即“world:anyone”。

  • Super

    超級管理者，也是一種特殊的Digest，此使用者角色可以對任意Zookeeper上的資料節點進行任何操作。

授權對象：ID

授權對象指的是權限賦予的使用者或一個指定實體，例如IP位址或是機器等。在不同的權限模式下，授權對象是不同的。 詳見下圖：

Zookeeper 入門第一篇

權限清單

Zookeeper 入門第一篇

權限管理

在設定ACL時，可以給zk用戶端和伺服器端的連接配接設定ACL，也可以在建立znode時；給znode設定ACL，在建立znode後，如果後zk用戶端來操作znode，隻有滿足權限要求時，才能完成相對應的操作。

API規定的權限清單具體可以參見：

1. org.apache.zookeeper.ZooDefs.Ids 
2. org.apache.zookeeper.ZooDefs.Perms

zk也可以實作自定義權限控制器，Zookeeper自定義的權限控制器需要實作：

org.apache.zookeeper.server.auth.AuthenticationProvider

Zookeeper服務中操作

在Zookeeper中有9個基本操作，如下圖所示：

Zookeeper 入門第一篇

更新Zookeeper操作是有限制的。delete或setData必須明确要更新的Znode的版本号，我們可以調用exists找到。如果版本号不比對，更新将會失敗，但是可以設定更新忽略版本号。

更新Zookeeper操作是異步的，非阻塞的。是以用戶端如果失去了一個更新（由于另一個程序在同時更新這個Znode 即樂觀鎖失敗），他可以在不阻塞其他程序執行的情況下，選擇重新嘗試或進行其他操作。

Watcher —— 資料變更的通知

ZooKeeper允許用戶端向服務端注冊一個Watcher監聽，當服務端的一些指定事件觸發了這個Watcher，那麼就會向指定用戶端發送一個事件通知來實作分布式的通知功能。

Watcher工作原理

ZooKeeper的Watcher機制主要包括用戶端線程、用戶端WatchManager和ZooKeeper伺服器三部分。在用戶端向ZooKeeper伺服器注冊Watcher的同時，會将Watcher對象存儲在用戶端的WatchManager中。當ZooKeeper伺服器觸發Watcher事件後，會向用戶端發送通知，用戶端線程從WatcherManager中取出對應的Watcher對象來執行回調邏輯。

Zookeeper 入門第一篇

Watcher事件

Watcher事件= 通知狀态(KeeperState) + 事件類型(EventType)。

Zookeeper 入門第一篇
  • 針對于NodeDataChanged事件，Node變更包括節點的資料内容和資料的版本号dataVersion。是以，即使使用相同的資料内容來更新，還是會觸發這個事件通知，因為對于ZooKeeper來說，無論資料内容是否變更，一旦有用戶端調用了資料更新的接口，且更新成功，就會更新dataVersion值。
  • NodeChildrenChanged事件會在資料節點的子節點清單發生變更的時候被觸發，這裡說的子節點清單變化特指子節點個數群組成情況的變更，即新增子節點或删除子節點，而子節點内容的變化是不會觸發這個事件。

Watcher的使用

  • 在建立ZooKeeper用戶端對象執行個體事，可以向構造方法中傳入一個預設的Watcher：

此時這個Watcher将作為整個ZooKeeper會話期間的預設Watcher，會一直被儲存在用戶端ZKWathcerManager的defaultWatcher中。

  • 查詢方法注冊觸發器

    getData、getChildren、exist三個接口來向ZooKeeper伺服器注冊Watcher。

Zookeeper 入門第一篇
  • exists操作上的watch，在被見識的Znode建立、删除或資料更新時被觸發。
  • getData操作上的watch，在被監視的Znode删除或資料更新時被觸發。在被建立時不能被觸發，因為隻有Znode一定存在，getData操作才會成功。
  • getChildren操作上的watch，在被監視的Znode的子節點建立或删除，或是這個Znode自身被删除時觸發。可以通過檢視watch事件類型來區分是Znode，還是他的子節點被删除：NodeDelete表示Znode被删除，NodeDeletedChanged表示子節點被删除。

Watch由用戶端所連接配接的ZooKeeper伺服器在本地維護，是以watch可以非常容易地設定、管理和分派。當用戶端連接配接到一個新的伺服器時，任何的會話事件都将可能觸發watch。另外，當從伺服器斷開連接配接的時候，watch将不會被接收。但是，當一個用戶端重建立立連接配接的時候，任何先前注冊過的watch都會被重新注冊。

轉載于:https://www.cnblogs.com/boothsun/p/8058622.html

資料結構與算法 網絡 作業系統
上一篇: docker學習總結第一篇
下一篇: SpringMVC學習總結第一篇一、前期工作（建立項目、導入依賴）二、案例三、總結

繼續閱讀