Zookeeper筆記分享

Zookeeper採用zap協議來保證數據的一致性

常見的數據一致性協議採用raft協議

 

參數解讀：

　　tickTime=2000：心跳包發送間隔時長

　　initLimit=10：leader與follower之間初始化時的最大超時時間，10X2000（理解爲第一次鏈接時的超時時長）

　　syncLimit=5：leader與follower之間正常通信超時時長，5X2000（集羣正常啓動以後的通信超時時長）

　　clientPort=2181：客戶端訪問服務端的端口號

選舉機制：

半數機制，推薦奇數臺服務器

先選本身，若是不行就優先選擇myid最大的，先入爲主

 

 

Zookeeper簡介

　　ZooKeeper 是一種分佈式協調服務，用於管理大型主機。在分佈式環境中協調和管理服務是一個複雜的過程。ZooKeeper 經過其簡單的架構和 API 解決了這個問題。ZooKeeper 容許開發人員專一於核心應用程序邏輯，而沒必要擔憂應用程序的分佈式特性。

分佈式應用

　　分佈式應用能夠在給定時間（同時）在網絡中的多個系統上運行，經過協調它們以快速有效的方式完成特定任務。一般來講，對於複雜而耗時的任務，非分佈式應用（運行在單個系統中）須要幾個小時才能完成，而分佈式應用經過使用全部系統涉及的計算能力能夠在幾分鐘內完成。

經過將分佈式應用配置爲在更多系統上運行，能夠進一步減小完成任務的時間。分佈式應用正在運行的一組系統稱爲集羣，而在集羣中運行的每臺機器被稱爲節點。

　　分佈式應用有兩部分， Server（服務器） 和 Client（客戶端） 應用程序。服務器應用程序其實是分佈式的，並具備通用接口，以便客戶端能夠鏈接到集羣中的任何服務器並得到相同的結果。 客戶端應用程序是與分佈式應用進行交互的工具。

 

　　ZooKeeper 是一個分佈式協調服務的開源框架。主要用來解決分佈式集羣中應用系統的一致性的問題，例如怎樣避免同時操做同一數據形成髒讀的問題。ZooKeeper 本質上是一個分佈式的小文件存儲系統。提供基於相似於文件系統的目錄樹方式的數據存儲，而且能夠對樹種 的節點進行有效管理。從而來維護和監控你存儲的數據的狀態變化。將經過監控這些數據狀態的變化，從而能夠達到基於數據的集羣管理。諸如：統一命名服務（dubbo）、分佈式配置管理（solr的配置集中管理）、分佈式消息隊列（sub/pub）、分佈式鎖、分佈式協調等功能。

 

Zookeeper 架構圖

Zookeeper集羣角色介紹

• Leader： ZooKeeper 集羣工做的核心 事務請求（寫操做）的惟一調度和處理者，保證集羣事務處理的順序性；集羣內部各個服務的調度者。 對於 create，setData，delete 等有寫操做的請求，則須要統一轉發給 leader 處理，leader 須要決定編號、執行操做，這個過程稱爲一個事務。

• Follower： 處理客戶端非事務（讀操做）請求 轉發事務請求給 Leader 參與集羣 leader 選舉投票2n-1臺能夠作集羣投票 此外，針對訪問量比較大的 zookeeper 集羣，還能夠新增觀察者角色

• Observer： 觀察者角色，觀察ZooKeeper集羣的最新狀態變化並將這些狀態同步過來，其對於非事務請求能夠進行獨立處理，對於事務請求，則會轉發給Leader服務器處理 不會參與任何形式的投票只提供服務，一般用於在不影響集羣事務處理能力的前提下提高集羣的非事務處理能力 一般來講就是增長併發的請求

ZooKeeper當中的主從與主備：

• 主從：主節點少，從節點多，主節點分配任務，從節點具體執行任務

• 主備：主節點與備份節點，主要用於解決咱們主機節點掛掉之後，如何選出來一個新的主節點的問題，保證咱們的主節點不會宕機

• 不少時候，主從與主備沒有太明顯的分界線，不少時候都是一塊兒出現

Zookeeper的特性

1. 全局數據的一致：每一個 server 保存一份相同的數據副本，client 不管連接到哪一個 server，展現的數據都是一致的
2. 可靠性：若是消息被其中一臺服務器接受，那麼將被全部的服務器接受
3. 順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息 a 在消息 b 前發佈，則在全部 server 上消息 a 在消息 b 前被髮布，偏序是指若是以個消息 b 在消息 a 後被同一個發送者發佈，a 必須將排在 b 前面
4. 數據更新原子性：一次數據更新要麼成功，要麼失敗，不存在中間狀態
5. 實時性：ZooKeeper 保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息

分佈式應用的優勢

• 可靠性 - 單個或幾個系統的故障不會使整個系統出現故障。
• 可擴展性 - 能夠在須要時增長性能，經過添加更多機器，在應用程序配置中進行微小的更改，而不會有停機時間。
• 透明性 - 隱藏系統的複雜性，並將其顯示爲單個實體/應用程序。

分佈式應用的挑戰

• 競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成。例如，共享資源只能在任意給定時間由單個機器修改。
• 死鎖 - 兩個或多個操做等待彼此無限期完成。
• 不一致 - 數據的部分失敗。

什麼是Apache ZooKeeper？

　　Apache ZooKeeper是由集羣（節點組）使用的一種服務，用於在自身之間協調，並經過穩健的同步技術維護共享數據。ZooKeeper自己是一個分佈式應用程序，爲寫入分佈式應用程序提供服務。

ZooKeeper提供的常見服務以下 :

• 命名服務 - 按名稱標識集羣中的節點。它相似於DNS，但僅對於節點。
• 配置管理 - 加入節點的最近的和最新的系統配置信息。
• 集羣管理 - 實時地在集羣和節點狀態中加入/離開節點。
• 選舉算法 - 選舉一個節點做爲協調目的的leader。
• 鎖定和同步服務 - 在修改數據的同時鎖定數據。此機制可幫助你在鏈接其餘分佈式應用程序（如Apache HBase）時進行自動故障恢復。
• 高度可靠的數據註冊表 - 即便在一個或幾個節點關閉時也能夠得到數據。

　　分佈式應用程序提供了不少好處，但它們也拋出了一些複雜和難以解決的挑戰。ZooKeeper框架提供了一個完整的機制來克服全部的挑戰。競爭條件和死鎖使用故障安全同步方法進行處理。另外一個主要缺點是數據的不一致性，ZooKeeper使用原子性解析。

ZooKeeper的好處

如下是使用ZooKeeper的好處：

• 簡單的分佈式協調過程
• 同步 - 服務器進程之間的相互排斥和協做。此過程有助於Apache HBase進行配置管理。
• 有序的消息
• 序列化 - 根據特定規則對數據進行編碼。確保應用程序運行一致。這種方法能夠在MapReduce中用來協調隊列以執行運行的線程。
• 可靠性
• 原子性 - 數據轉移徹底成功或徹底失敗，但沒有事務是部分的。

 

 

Zookeeper = 樹形節點znode文件系統+通知系統

 

每個znode節點默認存儲1MB的數據

一、一個領導者與多個跟隨者構成的集羣

二、集羣中過半節點存活，zookeeper集羣就能正常服務

三、全局數據一致：每個server都會同步當前最新的數據副本，client不管鏈接到那一臺server數據都是一致的

四、更新請求順序執行，來自同一個Client的更新請求按其發送順序依次執行（針對每個客戶端的更新請求順序執行）

五、實時性

 

Zookeeper的應用場景

• 分佈式鎖
• 集羣選主
• 統一命名服務
• 統一配置管理（監聽配置）
• 攜程配置中心 阿波羅
• 統一集羣管理（監聽集羣中節點變化）
• 服務器節點動態上下線
• 負載均衡

 

節點類型

 

 

zkCli指令 

zkCli.sh --server host:port：鏈接到指定的服務端

建立節點必需要設置數據

create (path | znode) data ：建立持久節點

create -s (path | znode) data ：建立持久順序編號目錄節點

create -e (path | znode) data ：建立短暫節點

create -e -s (path | znode) data ：建立短暫順序編號目錄節點

get znode：能夠獲取節點內存儲的數據和源數據

get znode watch：註冊某個節點的監聽服務

set znode newData：設置節點的值

ls znode：查看節點下的子節點

ls znode watch：註冊某個節點全部子節點的監聽服務

ls2 znode：查看節點的元數據

delete znode：刪除節點

rmr znode：遞歸刪除節點

stat znode：查看節點狀態

 

zookeeper就兩種集羣部署方式：單機部署和集羣部署

 

zk來最適合進行選主，和分佈式鎖（串行化方式）

 

ZK寫操做

 

任何一個分佈式系統都要知足分區容錯性 P，由於不能由於集羣中某一的節點宕機，就致使整個集羣不具有容錯性而致使不能再正常提供服務

 

 

什麼是AP模型？簡單的說就是集羣中通常以上節點宕機以後集羣仍然能夠提供服務，但其實它還涉及到一點，就是服務端每一次的請求都能收到響應，而ZK必須知足一半以上節點存活才能提供服務，並且在選舉Leader期間也是不對外提供服務的，由此推斷ZK輸入CP模型

 

 

 

1 eureka AP

eureka 保證了可用性，實現最終一致性。

Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)，其中說明了，eureka是不知足強一致性，但仍是會保證最終一致性

2 zookeeper CP

zookeeper在選舉leader時，會中止服務，直到選舉成功以後纔會再次對外提供服務，這個時候就說明了服務不可用，可是在選舉成功以後，由於一主多從的結構，zookeeper在這時仍是一個高可用註冊中心，只是在優先保證一致性的前提下，zookeeper纔會顧及到可用性

• C（一致性）：全部的節點上的數據時刻保持同步
• A（可用性）：每一個請求都能接受到一個響應，不管響應成功或失敗
• P（分區容錯）：系統應該能持續提供服務，即便系統內部有消息丟失（分區）

高可用、數據一致是不少系統設計的目標，可是分區又是不可避免的事情：

• CA without P：若是不要求P（不容許分區），則C（強一致性）和A（可用性）是能夠保證的。但其實分區不是你想不想的問題，而是始終會存在，所以CA的系統更多的是容許分區後各子系統依然保持CA。
• CP without A：若是不要求A（可用），至關於每一個請求都須要在Server之間強一致，而P（分區）會致使同步時間無限延長，如此CP也是能夠保證的。不少傳統的數據庫分佈式事務都屬於這種模式。
• AP wihtout C：要高可用並容許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每一個節點只能用本地數據提供服務，而這樣會致使全局數據的不一致性。如今衆多的NoSQL都屬於此類。

Zookeeper怎麼保證數據的一致性？

　　ZooKeeper寫數據的機制是客戶端把寫請求發送到leader節點上(若是發送的是follower節點，follower節點會把軍請求轉發到leader節點)， leader節點會把數據經過proposal請求發送到全部節點(包括本身)，全部的節點接受到數據之後都會寫到本身到本地磁盤上面，寫好了之後會發送一個ack請求給leader，leader只要接受到過半的節點發送ack響應回來，就會發送commit消息給各個節點，各個節點就會把消息放入到內存中（放內存是爲了保證高性能)，該消息就會用戶可見了。那麼這個時候，若是ZooKeeper要想保證數據一致性，就須要考慮以下兩個狀況∶

 

 

狀況一∶leader執行commit了，還沒來得及給follower發送commit的時候,leader宕機了，這個時候如何保證消息一致性?

 

解決︰當leader宕機之後，ZzooKeeper會選舉出來新的Leader，新的leader後動之後要到磁盤上面去檢查是否存在沒有comit到消息，若是存在，就繼續檢查看其餘follower有沒有對這條消息進行了commit，若是有過半節點對這條消息進行了ack，可是沒有commit，那麼新對1eader要完成commit對操做。

 

狀況二︰客戶端把消息寫到leader了，可是leader還沒發送proposal消息給其餘節點，這個時候leader宕機了，leader宕機後恢復的時候此消息又該如何處理?

 

解決∶客戶端把消息寫到leader了，可是leader還沒發送portal消息給其餘節點，這個時候leader宕機了，這個時候對於用戶來講，這條消息是寫失敗的。假設過了一段時間之後leader節點又恢復了，不過這個時候角色就變爲了follower了，它在檢查本身磁盤的時候會發現本身有一條消息沒有進行commit，此時就會檢測消息的編號，消息是有編號的，由高32位和低32位組成，高32位是用來體現是否發生過leader切換的，低32位就是展現消息的順序的。這個時候當前的節點就會根據高32位知道目前leader已經切換過了，因此就把當前的消息刪除，而後重新的leader同步數據，這樣保證了數據一致性。

Zookeeper的Observer節點

對應一個ZooKeeper集羣，咱們可能有多個客戶端，客戶端能任意鏈接其中一臺ZzooKeeper節點，可是全部的客戶端都只能往leader節點上面去寫數據，全部的客寧端能從全部的節點上面讀取數據。若是有客戶端鏈接的是follower節點，而後往follower上發送了寫數據的請求，這個時候follower就會把這個寫請求轉發給1eader節點處理。leader接受到寫請求就會往其餘節點（包括本身)同步數據，若是過半的節點接受到消息後發送回來ack消息，那麼leader節點就對這條消息進行commit,commit後該消息就對用戶可見了。由於須要過半的節點發送ack後，l1eader纔對消息進行comnit，這個時候會有一個問題，若是集羣越大，那麼等待過半節點發送回來ack消息這個過程就須要越久，也就是說節點越多雖然會增長集羣的讀性能，可是會影響到集事的寫性能，因此咱們通常建議ZooKeeper的集羣規模在3到5個節點左右。爲了解決這個問題，後來的Zookeeper中增長了一個observer 的角色，這個節點不參與投票，只是負責同步數據。好比咱們leader寫數據須要過半的節點發送ack響應，這個observer節點是不參與過半的數量統計的。它只是負責從leader同步數據，而後提供給客戶端讀取，因此引入這個角色目的就是爲了增長集羣讀的性能，而後不影響集羣的寫性能。用戶搭建集羣的時候能夠本身設置該角色。