Eureka的表兄弟Zookeeper理論基礎

Eureka的表兄弟Zookeeper

簡單介紹

Zookeeper是一個開源的分佈式應用程序協調服務器,主要功能包括配置維護,域名服務,分佈式同步,集羣管理等node

主要功能簡介

1、配置維護

  分佈式系統中,不少服務都是部署在集羣中的,就是多態服務器中部署着徹底相同的應用,他們的配置文件也是必須相同的,下面有一個場景,就是當咱們想要修改一個配置文件時,若是咱們經過手動修改參與集羣的全部機器上的應用配置文件時不只麻煩並且極其容易出錯,Zookeeper對配置文件的維護採用的事"發佈 / 訂閱模型",發佈者將修改號的集羣的配置文件發送到Zookeeper服務器的文件系統中,那麼訂閱者立刻就會收到通知,並主動去同步Zookeeper裏的配置文件,Zookeeper具備同步操做的原值性,確保參與集羣的機器說讀取的配置文件都能被正確的更新算法

2、域名服務

  如今的項目都是包含多個工程這種款式的,而有些工程就是專門爲其餘工程提供服務的,一個項目中就會存在不少這種想其餘工程提供服務的工程,而一個服務又可能存在多個提供者,服務的消費者消費起來就比較複雜,Zookeeper爲每個服務起了一個名稱,將這些名稱和對應提供服務的主機地址註冊到Zookeeper中,造成一個服務映射表,服務消費者經過服務名稱便可消費服務,服務的減小,添加,變動,只需修改Zookeeper中的服務映射表便可安全

  阿里的Dubbo就是使用的Zookeeper做爲服務域名服務器的服務器

3、分佈式同步

  在分佈式系統中,不少運算過程都是有分佈式集羣中若干服務器共同計算完成的,而且他們之間的運算還具備邏輯上的前後順序,Zookeeper就能夠協調這些服務間運算的過程,讓這些服務都同時監聽Zookeeper上的同一個znode,一旦起重工一個服務器的znode發生了改變,另外一個相應服務器就可以收到通知,並做出相應處理網絡

  好比上面這張邏輯圖,zookeeper能夠協調他們三個的前後順序分佈式

4、集羣管理

  集羣中最麻煩即便節點故障管理,Zookeeper會讓集羣選出一個節點做爲Master,監控全部的節點的健康情況,一個有節點故障,就會通知其餘的節點,使集羣中的其餘節點對於任務的分配做出相應的調整,Zookeeper除了發現故障外,還具備對故障進行甄別的功能,若是故障節點是能夠修復的,Zookeeper能夠修復它,若是不能修復則會告訴系統管理元錯誤的緣由讓管理員定位故障點,spa

  至於Master故障的話,Zookeeper內有選舉算法,選取新的節點擔任Master的職責對集羣進行管理對象

Zookeeper的一致性要求

順序一致性:blog

  • 從同一個客戶端發起的n多個事務請求,最終將會嚴格按照其發起請求的順序被應用到Zookeeper中繼承

原子性:

  • 全部事務請求的結果在集羣中全部的機器上的應用狀況是同樣的,也就是說要麼整個集羣中全部主機都成功應用某一個事務,要麼就沒有應用,不會出現集羣中個別主機應用了該事物,個別主機沒有應用的狀況

單一視圖:

  • 不管客戶端鏈接的是那一個Zookeeper服務器,其看到的服務端數據模型都是一致的

可靠性:

  • 一旦一個服務端成功的應用了一個事務,並完成對客戶端的響應,那麼該事務所引發的服務端狀態變動將會被一直保留下來,除非有另外一個事務又對其作了變動

實時性:

  • 這個實時性,指的是Zookeeper只能保證在必定的時間段內,客服端最終必定可以從服務器端讀取到最新的數據狀態,而不是一旦被應用,客服端就可以當即從服務端讀取到這個事務變動後的最新數據狀態

Zookeeper中的幾個重要概念

Session

  Session是指客戶端會話,Zookeeper對外的服務端口默認爲2181,客戶端啓動時,首先會與zk服務器創建一個TCP長鏈接,從第一次鏈接創建開始,客戶端會話的生命週期也開始了,經過這個長鏈接,客戶端可以經過心跳檢測保持與服務器的有效回話,也可以想zk服務器發起請求並接受響應,同時還能經過該鏈接接受來自服務器的Watcher時間通知

  Session的SessionTimeout值用來設置一個客戶端會話的超時時間,當因爲服務器壓力過大、網絡延遲、客戶端主動斷開鏈接等各類緣由致使的福護短鏈接斷開時,只要在SessionTimeout規定的有效時間內從新鏈接上集羣中的任意一個服務器,那麼以前建立的會話仍然有效

Znode

  zk的文件系統採用屬性層次化的目錄結構,每一個目錄都在zk中都叫作一個znode,每一個znode都擁有一個惟一的路徑標識,Znode能夠包含數據和子Znode(零時節點不能有子Znode),Znode中的數據能夠有多個版本,因此查詢某路徑下的數據須要帶上版本號,客戶端應用能夠在Znode上設置監視器(Watcher)

Watcher機制

  zk經過Watcher機制實現發佈訂閱模式,zk提供了分佈式數據的發佈訂閱功能,一個發佈者可以讓多個訂閱者同時監聽某一個主題對象,當這個主題對象狀態發生改變是,會通知全部訂閱者,是他們可以做出相應的處理,ZK容許哭護短想服務器註冊一個Watcher監聽,當服務端的一些指定事件觸發這個Watcher時,那麼就會向指定的客戶端發送一個事件通知,而這個事件通知則是經過TCP長鏈接的Session完成的

ACL:訪問控制列表

  ACL全稱爲Access Control List,用於控制資源的訪問權限,是ZK數據安全的保障,ZK利用ACL策略控制Znode節點的訪問權限,若是節點建立,節點數據讀寫,節點刪除,讀取子節點列表,設置節點權限等

  在傳統的文件系統中,ACL分爲兩個維度,組與權限,一個組能夠包含多個權限,一個文件或者目錄擁有了某個租的權限即又有了組裏全部的權限,文件或子目錄默認會繼承父目錄的ACL

  在ZK中,Znode的ACL是沒有繼承關係的,每個Znode的權限都是獨立控制的,只有哭護短知足Znode設置的權限要求時,才能完成相應的操做,ZK的ACL分爲三個維度,分別爲: 受權策略scheme、用戶id、用戶權限permission。

相關文章
相關標籤/搜索