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的特性
- 全域資料的一致：每個 server 保存一份相同的資料副本，client 無論鏈接到哪個 server，展示的資料都是一致的
- 可靠性：如果訊息被其中一臺服務器接受，那么將被所有的服務器接受
- 順序性：包括全域有序和偏序兩種：全域有序是指如果在一臺服務器上訊息 a 在訊息 b 前發布，則在所有 server 上訊息 a 在訊息 b 前被發布，偏序是指如果以個訊息 b 在訊息 a 后被同一個發送者發布，a 必須將排在 b 前面
- 資料更新原子性：一次資料更新要么成功，要么失敗，不存在中間狀態
- 實時性：ZooKeeper 保證客戶端將在一個時間間隔范圍內獲得服務器的更新資訊，或者服務器失效的資訊
分布式應用的優點
- 可靠性 - 單個或幾個系統的故障不會使整個系統出現故障，
- 可擴展性 - 可以在需要時增加性能，通過添加更多機器，在應用程式配置中進行微小的更改，而不會有停機時間，
- 透明性 - 隱藏系統的復雜性，并將其顯示為單個物體/應用程式，
分布式應用的挑戰
- 競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成，例如，共享資源只能在任意給定時間由單個機器修改，
- 死鎖 - 兩個或多個操作等待彼此無限期完成，
- 不一致 - 資料的部分失敗，
什么是Apache ZooKeeper？
Apache ZooKeeper是由集群（節點組）使用的一種服務，用于在自身之間協調，并通過穩健的同步技術維護共享資料，ZooKeeper本身是一個分布式應用程式，為寫入分布式應用程式提供服務， ZooKeeper提供的常見服務如下 :- 命名服務 - 按名稱標識集群中的節點，它類似于DNS，但僅對于節點，
- 配置管理 - 加入節點的最近的和最新的系統配置資訊，
- 集群管理 - 實時地在集群和節點狀態中加入/離開節點，
- 選舉演算法 - 選舉一個節點作為協調目的的leader，
- 鎖定和同步服務 - 在修改資料的同時鎖定資料，此機制可幫助你在連接其他分布式應用程式（如Apache HBase）時進行自動故障恢復，
- 高度可靠的資料注冊表 - 即使在一個或幾個節點關閉時也可以獲得資料，
以下是使用ZooKeeper的好處：
- 簡單的分布式協調程序
- 同步 - 服務器行程之間的相互排斥和協作，此程序有助于Apache HBase進行配置管理，
- 有序的訊息
- 序列化 - 根據特定規則對資料進行編碼，確保應用程式運行一致，這種方法可以在MapReduce中用來協調佇列以執行運行的執行緒，
- 可靠性
- 原子性 - 資料轉移完全成功或完全失敗，但沒有事務是部分的，
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：查看節點狀態- 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同步資料，然后提供給客戶端讀取，所以引入這個角色目的就是為了增加集群讀的性能，然后不影響集群的寫性能，用戶搭建集群的時候可以自己設定該角色，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/242801.html
標籤：其他