《zookeeper原理與實踐》筆記

第1章 分佈式架構

1.1 分佈式

分佈式特色：分佈性、對等性、併發性、缺少全局時鐘、故障老是會發生。

分佈式問題：通信異常、網絡分區（腦裂）、三態、節點故障。

 

1.2 ACID到CAP/BASE

事務：由一系列對系統中數據進行訪問與更新的操做所組成的一個程序執行邏輯單元。

ACID：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。

隔離級別：讀未提交、讀已提交（解決髒讀）、可重複讀（解決髒讀和不可重複讀）、串行化（解決髒讀，不可重複讀和幻讀）。

 

分佈式事務：是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於分佈式系統的不一樣節點之上。

CAP定理：一個分佈式系統不能同時知足一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance），最多知足兩個。

BASE理論：是對CAP中一致性和可用性權衡的結果，來源於大型互聯網系統分佈式實踐的總結。核心思想是能夠放棄強一致性，採用適當的方式使系統達到最終一致性。是基本可用（Basically Available）、軟狀態（Soft state）、最終一致性（Eventually consistent）的縮寫。

 

 

第2章 一致性協議

2.1 2PC 二階段提交協議

二階段提交將一個事務處理分爲投票和執行兩個階段，核心是對事務採用先嚐試後提交的處理方式。目前絕大多數關係型數據庫採用二階段提交完成事務處理。

優勢：原理簡單，實現方便。

缺點：同步阻塞、單點問題、數據不一致（腦裂）、太過保守。

同步阻塞：是兩階段最大最嚴重的問題，極大影響性能，由於全部參與者都必須等待其餘參與者完成，才能進行下一階段操做。

單點問題：協調者一旦掛了，整個事務處理沒法運轉，另外收不到請求的參與者會一直處於鎖定事務資源的狀態中。

數據不一致：一部分收到Commit請求的參與者完成事務提交，而沒收到的參與者沒法提交，整個分佈式系統出現數據不一致。

太過保守：比較脆弱，任何一個節點超時失敗都會致使整個事務失敗。

 

階段一：提交事務請求

①協調者發起事務詢問：協調者向全部參與者發送事務內容，詢問是否能夠執行事務提交操做，並等待響應。

②參與者執行事務操做：參與者執行事務操做，並將redo和undo寫到事務日誌。

③參與者將詢問結果響應給協調者：返回Yes或No。

 

階段二：執行事務提交

A、當所有Yes，則提交事務

①協調者發送提交請求：協調者向全部參與者發出Commit請求。

②參與者執行事務提交：參與者收到Commit請求後，正式執行事務提交操做，完成提交後釋放整個事務執行期間佔用的系統資源。

③參與者將事務提交結果響應給協調者：返回Ack消息。

④協調者完成事務：協調者接受到全部參與者響應的Ack消息後，完成事務。

 

B、當某一個存在No或超時，則中斷事務

①協調者發送回滾請求：協調者向全部參與者發出Rollback請求。

②參與者執行事務回滾：參與者收到Rollback請求後，執行事務回滾操做，完成回滾後釋放整個事務執行期間佔用的系統資源。

③參與者將事務回滾結果響應給協調者：返回Ack消息。

④協調者中斷事務：協調者接受到全部參與者響應的Ack消息後，完成事務中斷。

 

2.2 3PC 三階段提交協議

將二階段提交協議的第一個階段一分爲二，增長詢問階段，造成了由CanCommit、PreCommit和DoCommit三個階段組成的事務提交協議。

優勢：當可能失敗時，由於快速發現失敗，下降了參與者的同步阻塞範圍，是最大優勢。

缺點：多出的詢問階段會增長總體阻塞耗時。

 

2.3 Paxos算法

Paxos算法引入「過半」理念，也就是少數服從多數的原則來避免同步阻塞問題；同時支持分佈式節點角色之間的輪換，來避免單點問題和一致性（腦裂）問題。

拜占庭將軍問題：從理論上來講，在分佈式計算領域，試圖在異步系統和不可靠的通道上來達到一致性狀態是不可能的。所以，在一致性研究過程當中，都假設信道是可靠的。

Paxos問題描述：假設有一組能夠提出提案的進程集合，那麼對於一個一致性算法來講須要保證如下幾點：

①在這些被提出的提案中，只有一個會被選定。

②若是沒有提案被提出，就不會有被選定的提案。

③當一個提案被選定後，進程能夠獲取被選定的提案。

 

Paxos問題難點：有三種參與角色，分別位Proposer、Acceptor、Learner。不一樣參與者能夠消息通訊，但存在如下問題：

①任何一個參與者都不穩定，隨時可能失敗或重啓。

②消息傳輸過程當中可能延遲、重複和丟失，但不會被篡改。

 

Chubby：Google開發的粗粒度的分佈式鎖服務，Paxos算法的工程實現者。其開源參考實現版本爲Zookeeper。

 

 

第3章 Zookeeper與Paxos

3.1 初識Zookeeper

ZK是一個開源的分佈式協調服務，也是一個分佈式數據一致性的解決方案。

ZK設計目標：致力於提供一個高性能、高可用，具備嚴格的順序一致性（主要是寫操做的嚴格順序性）的分佈式協調服務。

ZK保證的分佈式一致性特性：順序一致性、原子性、單一視圖、可靠性、實時性。

順序一致性：同一個客戶端發起的事務請求，最終將會嚴格的按照其發起順序被應用到ZK中。

 

集羣角色：Leader（讀寫，事務請求協調者）、Follower（讀、參與Leader選舉、參與寫操做的「過半寫成功」策略）、Observer（讀）。

會話：基於客戶端與服務端的TCP長鏈接和會話超時時間實現。

ZNode：簡單數據模型是內存中的一顆目錄樹，樹節點叫Znode。分爲持久節點和臨時節點兩大類，節點的順序屬性是由父節點維護的一個自增數字後綴。

 

3.2 ZAB協議

ZAB是ZK實現分佈式數據一致性的核心算法。ZAB兩種基本模式：崩潰恢復和消息廣播。

ZAB協議與Paxos算法的區別：Paxos是一種通用的分佈式一致性算法，而ZAB是專門爲ZK設計的支持崩潰可恢復的原子消息廣播算法。

ZXID：64位全局惟一遞增的事務ID，低32位保存單調遞增計數器，高32位保存Leader週期epoch的編號。

進程狀態：LOOKING（Leader選舉階段）、FOLLOWING（Follower角色）、LEADING（Leader角色）、OBSERVING。

 

3.3 消息廣播

ZAB消息廣播方式是一個簡化的2PC，但去除了中斷邏輯（採用過半寫成功策略），而且用崩潰恢復來解決協調者（Leader）單點問題。

ZAB事務請求處理流程（相似2PC）：全部事務請求必須由一個全局惟一的Leader服務器來協調處理，Leader負責將一個客戶端事務請求轉換成一個事務Proposal（提議），並將該Proposal分發給集羣中全部的Follower服務器並等待其反饋，一旦超過半數的Follower服務器進行正確ACK反饋（投票）後，那麼Leader就會再次向全部的Follower服務器分發Commit消息。要求其將前一個的Proposal進行提交。

 

3.4 崩潰恢復

啓動條件：Leader崩潰、重啓、與過半Follower網絡中斷時。

退出條件：完成Leader選舉，而且新Leader上的全部Proposal已與過半機器完成數據同步，這時新Leader才能接受客戶端事務請求。

Leader選舉算法：擁有最高編號（ZXID最大）事務Proposal的機器會成爲Leader。此算法優勢是爲了省去新Leader檢查Proposal的提交和丟棄工做的這兩步操做。

Proposal提交檢查：是指ZAB協議須要確保那些已經在Leader服務器上提交的事務最終被全部服務器都提交。

Proposal丟棄檢查：是指ZAB協議須要確保丟棄那些只在Leader服務器上被提出的事務。

 

3.5 ZAB與Paxos聯繫和區別

相同點：都是一個Leader多個Follower，提案提交都採用過半原則，而且都有Leader週期epoch。

區別：Leader選舉算法不同，Paxos的新Leader會向全部機器收集老Leader提出的提案，並將他們提交。而ZAB增長髮現和同步階段，擁有最高編號的事務提案會成爲Leader。

本質區別：設計目標不同，Paxos用於構建一個分佈式的一致性狀態機系統，ZAB則用於構建一個例如Zookeeper這樣的高可用的分佈式數據主備系統。

 

 

第4章 使用Zookeeper

4.1 部署與運行

部署模式：單機、僞集羣、集羣。

zkCli.sh客戶端命令：create、ls、get、set、delete。

zkServer.sh服務器命令：status、start、stop、restart、help。

 

開源客戶端：zkClient、Curator。

 

 

第5章 Zookeeper典型應用場景

5.1 數據發佈/訂閱

即配置中心，ZK採用推拉結合方式：客戶端向服務器註冊本身要關注的節點，一旦節點數據發生變動，服務器向客戶端發送watcher事件通知（push），客戶端接收到通知後，須要主動到服務器獲取最新的數據（pull）。

 

5.2 命名服務

與JNDI相似，幫助應用系統經過一個資源引用的方式來實現對資源的定位和使用。能夠利用目錄樹結構和ZNode的順序屬性來生成分佈式全局惟一ID。

 

5.3 分佈式協調/處理

基於ZK的watcher註冊與異步通知機制，一般作法是：不一樣客戶端都對ZK同一個數據節點進行watcher註冊，監聽數據節點變化。能夠實現心跳檢測、工做進度彙報、系統調度等。

 

5.4 集羣管理

包括集羣監控和集羣控制兩大塊。能夠實現機器註冊、任務分發、狀態彙報、動態分配、機器上下線、機器監控等。

 

5.5 Master選舉

利用ZK特性實現，即ZK保證客戶端沒法重複建立一個已經存在的數據節點。作法是：同時多個客戶端請求建立同一個節點，那麼最終必定只有一個客戶端可以建立成功。

 

5.6 分佈式鎖

排他鎖

A、獲取鎖

①多個客戶端同時在/el節點下建立同名臨時子節點/el/lock，最終只有一個能建立成功，那麼就獲取到鎖。

②獲取鎖失敗的客戶端在該/el節點註冊一個子節點變動的watcher監聽。

B、釋放鎖

擁有鎖的客戶端宕機、用完主動刪除。

 

共享鎖

A、獲取鎖

①多個客戶端在/sl節點下建立順序臨時子節點/sl/host-讀寫類型[RW]-序號。

②當寫操做時，對比本身序號小的節點註冊節點變動watcher監聽。

③當讀操做時，對比本身序號小的寫操做節點註冊節點變動watcher監聽，當比本身小的都是讀操做節點時，則直接獲取鎖。

B、釋放鎖

擁有鎖的客戶端宕機、用完主動刪除。

 

5.7 分佈式隊列FIFO

相似所有爲寫操做的共享鎖模型。

A、獲取鎖

①多個客戶端在/queue節點下建立順序臨時子節點/queue/host-序號。

②對比本身序號小的節點註冊節點變動watcher監聽。

 

5.8 分佈式屏障

①多個客戶端在/barrier節點（內容爲數字N）下建立臨時子節點/barrier/host。

②檢查子節點數量是否小於N，知足則對/barrier節點註冊一個子節點變動的watcher監聽。

 

5.9 ZK在大型分佈式系統的應用

Hadoop：ZK主要實現高可用HA功能。如：HDFS的namenode、YARN的resourcemanager。

HBase：HRegionServer的高可用，RootRegion自身的位置管理，Region狀態管理等，Replication管理。

Kafka：Broker的註冊管理、Topic節點（Topic分區信息與Broker的映射關係）的管理、生產者動態負載均衡（生產者經過對「broker的增減」，「topic的增減」，「topic與broker映射關係變化」等註冊watcher監聽）、消費者動態負載均衡（同上）。

Dubbo：服務註冊中心。

 

 

第6章 Zookeeper技術內幕

6.1 系統模型

ZNode：命名空間樹的節點，根節點爲「/」，相似Unix文件系統風格。

ZK事務：可以改變ZK服務器狀態的操做。包括ZNode建立刪除、數據節點內容更新、客戶端會話建立與失效等。

ZXID：事務ID，全局自增有序。節點stat中有czxid（建立）、mzxid（最後一次修改）、pzxid（子節點列表最後一次修改，不含子節點內容變動）三種類型。

節點類型：持久、臨時、順序。

臨時節點：臨時節點生命週期和客戶端會話綁定，而不是TCP鏈接。

節點版本：表示修改次數，剛建立爲0次。經過樂觀鎖和CAS校驗機制來保證原子性操做。分爲version（節點數據內容）、cversion（子節點列表）、aversion（節點ACL變動）三種類型。

 

watcher機制：包括客戶端線程、客戶端WatchManager和ZK服務器三部分。實現過程分爲三個階段：客戶端註冊watcher、服務端處理watcher和客戶端回調watcher。

watcher事件：由keeperState和EventType組合實現。keeperState分爲4種：SyncConnected、Disconnected、Expired、AuthFailed。而eventType分爲5種：None、NodeCreated、NodeDeleted、NodeDataChanged、NodeChildrenChanged。

watcher特性：一次性、客戶端串行執行、輕量級。

 

ACL：一條ACL信息的格式爲scheme（權限模式）：id（受權對象）：permission（權限）。

scheme權限模式：分爲4種，即IP、Digest（用戶名：密碼）、world、super。

permissionL權限：分爲5種，即CREATE、READ、WRITE、DELETE、ADMIN。

 

Jute：zk的序列化組件。

 

6.2 客戶端

zk客戶端主要有四個核心組件：ZK實例、ClientWatcherManager、HostProvider、ClientCnxn。

zk服務端組件：NIOServerCnxn負責維護每個客戶端鏈接，採用TCP長鏈接。

 

6.3 會話

session會話的5個狀態：connecting、connected、reconnecting、reconnected、close。

會話四個基本屬性：sessionID、timeout、ticktime（下次會話超時時間點）、isClosing。

會話採用「分桶策略」管理，爲了高效低耗的實現會話的超時檢查和清理。

分桶策略：是指將相似的會話放在同一區塊中管理，以便ZK對會話進行不一樣區塊的隔離以及同一區塊的統一處理。

 

會話重連：當客戶端與服務器網絡鏈接斷開後，ZK客戶端會自動進行反覆的重連，直到最終成功鏈接上ZK集羣中的一臺機器。此時若還在會話超時時間內，則重連成功；不然會話失效過時。

會話轉移：當網絡鏈接斷開後，重連到另一臺服務器，則客戶端會話將從舊服務器轉移到新服務器。

 

6.4 服務器啓動

leader選舉是單機和集羣模式啓動最大的不一樣點。默認的leader選舉算法爲FastLeaderElection。根據服務器SID、最新的zxid、當前的服務器epoch來生成一個投票。簡單而言，哪一個服務器處理過的數據越新，就越有可能成爲leader。zxid相同時，sid最大的成爲leader。

 

6.5 Leader選舉

ZK服務器的三種角色：Leader、Follower、Observer。

Quorum：過半機器數。計算公式Quorum=（n/2+1）。

Vote：投票的基本元素包含：所推舉的服務器sid，所推舉服務器的zxid，如（SID，ZXID）。

 

Leader選舉概述：

A、服務器啓動期間的Leader選舉（當首臺機器啓動時不會選舉，此時無leader，只有當第2臺啓動時纔會觸發）

①每一個服務器會發出一個投票，初始都投給本身，如（1，0）、（2，0）。

②接收來自各個服務器的投票，並校驗投票有效性，如是否爲本輪投票，是否來自LOOKING狀態的服務器。

③將接收到的別人的N-1個投票和本身的投票PK，選出N個投票中的最大者，若最大者不是本身，則變動投票，經過將收到的最大者投票再次發出，來發起第二輪投票；若最大者是本身則沒有第二輪投票。PK規則：先比較ZXID，相同則比較SID。

④統計全部投票，判斷是否已經有過半的機器接收到相同的投票信息。

⑤改變服務器狀態爲Leading或Following。

 

B、服務器運行期間的Leader選舉（非Leader機器增減不會選舉，僅leader掛了纔會）

①每一個Follower服務器變動狀態爲LOOKING。

②每一個服務器會發出一個投票（SID，ZXID），第一輪投票都投給本身。

③④⑤與上述相同。

 

zk服務器狀態：分別爲LOOKING、FOLLOWING、LEADING和OBSERVING。

 

FastLeaderElection選舉算法核心概念：

外部投票：特指其餘服務器發來的投票。

內部投票：服務器自身當前的投票。

選舉輪次：ZK服務器Leader選舉的輪次，即logicalClock。

PK：將內部投票和外部投票進行一個對比來肯定是否須要變動內部投票。

sendQueue：選票發送隊列。

recvQueue：選票接收隊列。

recvSet：選票歸檔集合。不管是否發生了選票變動，都會將剛剛收到的那份外部選票放入選票集合recvSet中進行歸檔。完成歸檔後，開始統計選票。

 

6.6 請求處理

ZK中每個事務請求都須要集羣中過半機器投票承認後，才能被真正應用到ZK內存數據庫中去。

事務處理相關概念：生成並廣播提議Proposal、收集ACK消息反饋、廣播Commit。

 

6.7 數據與存儲

ZK數據存儲分爲內存和硬盤兩部分。內存數據模型是一棵樹DataTree。

ZKDatabase：ZK內存數據庫，負責管理ZK全部會話，DataTree存儲和事務日誌。會定時向磁盤dump快照數據，同時在zk啓動時，會經過磁盤上的事務日誌和快照數據文件恢復成一個完整的內存數據庫。

dataDir：快照數據目錄。名爲「snapshot.ZXID」二進制文件。

dataLogDir：事務日誌目錄。名爲「log.ZXID」的二進制文件。

 

 

第7章 Zookeeper運維

7.1 配置詳解

tickTime：配置zk中最小時間單元的長度，其餘時間都是以其倍數來表示，單位毫秒。

initTime：配置Leader服務器等待Follower啓動，並完成數據同步的時間。集羣龐大時須要加大。

syncTime：配置Leader與Follower之間進行心跳檢測的最大延時時間。

snapCount：配置兩次數據快照之間事務操做次數。

 

7.2 四字命令

經過telnet客戶端登陸zk對外服務的2181端口，而後輸入四字命令。

 

7.3 集羣組成

zk集羣只能部署爲奇數個是錯誤的認識。任意臺機器都能部署且可以正常運行。若要進一步知足集羣可用，則需知足「過半存活便可用」的特性。

過半存活便可用：一個zk集羣要對外提供一個「可用」的服務，那麼集羣中必需要有過半的機器正常工做而且彼此之間可以正常通訊。

基於該特性，若想搭建容許F臺down掉的集羣，則服務器數量應該爲2*F+1臺。例如：6臺和5臺相比，都是隻容許2臺down掉，在容災能力上沒有任何優點，只會浪費資源，所以官方建議部署奇數個。