深入剖析Zookeeper原理（一）整體設計

1. ZK集群架構設計與特性

1. ZK集群架構設計：

ZK主要分為三種角色：

• Leader（領導者）：一個Zookeeper集群同一時間只會有一個實際作業的Leader，它會發起并維護與各Follwer及Observer間的心跳，所有的寫操作必須要通過Leader完成再由Leader將寫操作廣播給其它服務器，

• Follower（跟隨者）：一個Zookeeper集群可能同時存在多個Follower，它會回應Leader的心跳，Follower可以處理客戶端的讀請求，但寫請求轉發給Leader處理，并且負責參與新 leader的選舉、回應 leader 的提議，

• Observer（觀察者）：角色與Follower類似，但是無投票權，不參加選舉， 也不回應提議，

  其次是 Observer不需要將事務持久化到磁盤，一旦 Observer被重啟，需要從 leader 重新同步整個名字空間，Observer可以接收客戶端連接，將寫請求轉發給leader，設計Observer的目的是為了擴展系統，提升讀取速度，

2. ZK的網路架構：

Zookeeper的作業集群可以簡單劃分為Leader和follower，后續章節會講解Leader是通過內部選舉確定的，

Leader和各個follower是互相通信的，對于zk系統的資料都是保存在記憶體里面的，為防止資料丟失， 也會備份一份在磁盤上，對于每個zk節點而言，可以看做每個zk節點的命名空間是一樣的，也就是有同樣的資料，

如果Leader掛了，zk集群會重新選舉，在毫秒級別就會重新選舉出一個Leaer，集群中除非有一半以上的zk節點掛了，整個ZK集群才不可用，

3. ZK特性：

• 順序一致性：客戶端發出的更新操作命令， 嚴格地按照其發起的順序在Zookeeper中執行，

  Zookeeper的所有寫操作都通過主機點執行，從節點做復制同步操作，這樣所有節點的更新順序都和主節點相同，

  詳情可查閱FollowerRequestProcessor->CommitProcessor.processRequest()

  采用LinkedList存盤請求

• 實時性：ZooKeeper 保證客戶端在一定的時間間隔內獲得最新資料結果，比如客戶端通過Watch機制監聽不同的節點， 只要發生變化， 都能實時獲取資訊變化，

• 原子性：領導者在同步資料時會保證事務性，一次資料的更新操作，要么都成功，要么都失敗， 沒有其他的狀態，

2. CAP定理

CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（磁區容錯性）這三個基本需求，最多只能同時滿足其中的2個，

Consistency（一致性）：

在分布式環境中，一致性是指資料在多個副本之間是否能夠保持資料一致的特性，例如一個將資料副本分布在不同分布式節點上的系統來說，如果對第一個節點的資料進行了更新操作并且更新成功后，其他節點上的資料也應該得到更新，并且所有用戶都可以讀取到其最新的值，那么這樣的系統就被認為具有強一致性（或嚴格的一致性），

Availability（可用性）：

可用性是指系統提供的服務必須一直處于可用的狀態，對于用戶的每一個操作請求總是能夠在有限的時間內回傳結果，有效的時間是指，對于用戶的一個操作請求，系統必須能夠在指定的時間（即回應時間）內回傳處理結果，如果超過了這個時間范圍，那么系統就被認為是不可用的，

回傳結果是可用性的另一個非常重要的指標，它要求系統在完成對用戶請求的處理后，回傳一個正常的回應結果，正常的回應結果通常能夠明確的反映出對請求的處理結果，即成功或失敗，而并非一個不明確的結果，

Partition Tolerance（磁區容錯性）：

磁區容錯性約束了一個分布式系統需要具有如下特性：分布式系統在遇到任何網路磁區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網路環境都發生了故障，

什么是網路磁區？它是指在分布式系統中，不同的節點分布在不同的網路（比如機房或異地網路等）中，由于一些特殊的原因（比如DNS，路由等故障）導致這些子網路之間出現網路不連通的狀況，但各個子網路的內部網路是正常的，從而導致整個系統的網路環境被切分成了若干個孤立的區域，形成了不同的網路磁區，

由于一個分布式系統無法同時滿足上面的三個需求，而只能滿足其中的兩項，因此在依據CAP定理應用的時候，需要根據業務需求權衡考慮，拋棄其中的一項，那Zookeeper是如何運用的？它又遵循了哪兩種特性？

ZK在CAP定理中， 保證的是CP特性，

ZK為什么不能滿足可用性呢？

作為ZK的核心實作演算法Zab，就是解決了分布式系統下資料如何在多個服務之間保持同步問題的，如果ZK下所有節點都斷開了，或者集群中出現網路分割的故障，ZK會將他們從自己管理范圍內剔除出去，外界就不能訪問到這個節點，即便這些節點本身是健康的，可以正常提供服務，

在剔除故障節點的這段時間內，ZK可能會丟棄一些請求，消費者程式需要重新請求才能獲得結果，

ZK在什么情況下是不能保證可用呢？

之前我們講過，ZK的所有寫請求都必須經由leader節點處理， 所以ZK在進行leader選舉時集群都是不可用的，

客戶端可以考慮加入重試機制來做補償

3. ZK資料結構與存盤

1. ZK資料結構模型

在Zookeeper當中， 資料是如何存盤呢， 它有怎樣的特點？其實ZK的資料結構類似linux中的檔案系統結構

ZK命名空間中的每個節點路徑都是唯一標識， 命名空間是可以支持層級的，

ZNode節點屬性：

[zk: localhost:2181(CONNECTED) 1] get /testNode
test
cZxid = 0x2
ctime = Fri Aug 06 22:28:23 CST 2020
mZxid = 0x2
mtime = Fri Aug 06 22:28:23 CST 2020
pZxid = 0x2
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

具體可以查看org.apache.zookeeper.data.Stat原始碼：

• cZxid ：創建的事務標識，
• ctime：創建的時間戳，
• mZxid：修改的事務標識，每次修改操作（set）后都會更新mZxid和mtime，
• mtime：修改的時間戳，
• pZxid：直接子節點最后更新的事務標識，子節點有變化（創建create、修改set、洗掉delete，rmr）時，都會更新pZxid，
• cversion ：直接子節點的版本號，當子節點有變化（創建create、修改set、洗掉delete，rmr）時，cversion 的值就會增加1，
• dataVersion ：節點資料的版本號，每次對節點進行修改操作（set）后，dataVersion的值都會增加1（即使設定的是相同的資料），
• aclVersion ：節點ACL的版本號，每次節點的ACL進行變化時，aclVersion 的值就會增加1，
• ephemeralOwner：當前節點是臨時節點（ephemeral node ）時，這個ephemeralOwner的值是客戶端持有的session id，
• dataLength：節點存盤的資料長度，單位為 B （位元組），
• numChildren：直接子節點的個數，

2. ZK資料存盤方式

上面講過ZK的資料結構模型， 實質上是類似樹形的結構， 那ZK的資料是存盤在哪里呢？ 支持哪些存盤方式？

資料存盤方式分為三類：

1. 記憶體資料

   查看org.apache.zookeeper.server.DataTree與DataNode原始碼

   結合ZK節點來講解， node和tree的關聯，

   查看ZKDatabase原始碼

   在記憶體資料庫中，存盤了整棵樹的內容，包括所有的節點路徑、節點資料、ACL資訊，Zookeeper會定時將這這些資料存盤到磁盤上，

   

   記憶體資料結構分為三類：

   1. DataTree是記憶體資料存盤的核心
   2. DataNode是資料存盤的最小單元，內部主要保存資料內容、ACL串列、節點狀態資訊
   3. ZKDatabase是ZK的記憶體資料庫，管理Zookeeper的所有會話、DataTree存盤和事務日志，

2. 事務日志

   查看ZK資料存盤目錄， /data/zookeeper/version-2

   -rw-r–r--. 1 root root 67108880 Mar 24 11:17 log.100000001
   -rw-r–r--. 1 root root 67108880 Mar 25 01:23 log.1000001c4
   -rw-r–r--. 1 root root 67108880 Mar 25 01:45 log.300000001
   -rw-r–r--. 1 root root 67108880 Mar 26 12:44 log.300000005

   ZK集群會有一個專門的dataDir目錄，用來存盤事務日志檔案，該目錄確定了當前ZK使用的事務日志格式版本號，當下次某個ZK版本對事務日志格式進行變更時，此目錄也會變更，并在目錄下生成一系列檔案大小一致(64MB)的檔案，

   進入ZK目錄/usr/local/zookeeper-3.4.14， 選取最新的日志檔案，再執行：

   java -classpath .:./lib/slf4j-api-1.7.25.jar:./zookeeper-3.4.14.jar org.apache.zookeeper.server.LogFormatter /data/zookeeper/version-2/log.100000001 > log1.log
   

   產生的日志內容：

   8/9/21 8:55:19 PM EDT session 0x20003a778cc0012 cxid 0xa9 zxid 0x1000001bc delete '/lock-namespace/shared_lock/order/W-0000000016
   
   8/9/21 8:55:29 PM EDT session 0x20003a778cc0012 cxid 0xb0 zxid 0x1000001bd delete '/lock-namespace/shared_lock/order/W-0000000017
   
   8/9/21 9:46:18 PM EDT session 0x20003a778cc0012 cxid 0xb1 zxid 0x1000001be create '/lock-namespace/shared_lock/order/W-0000000018,#3139322e3136382e3132332e313033,v{s{31,s{'world,'anyone}}},T,19
   
   8/9/21 9:46:38 PM EDT session 0x20003a778cc0012 cxid 0xb4 zxid 0x1000001bf delete '/lock-namespace/shared_lock/order/W-0000000018
   
   

3. 資料快照（snapshot）

   資料快照用來記錄Zookeeper服務器上某一時刻的全量記憶體資料內容，并將其寫入指定的磁盤檔案中，

   Zookeeper在進行若干次事務日志記錄后，將記憶體資料庫的全量資料Dump到本地檔案中，這個就是資料快照，

   快照查看命令：

   java -classpath .:./lib/slf4j-api-1.7.25.jar:./zookeeper-3.4.14.jar org.apache.zookeeper.server.SnapshotFormatter /data/zookeeper/version-2/snapshot.100000000 > snap1.log
   

   查看原始碼： SyncRequestProcessor.run() -> zks.takeSnapshot()

   在新增log（txn log）檔案數量達到snapCount/2 + Random.nextInt(snapCount/2)時，將會對zkDatabase(記憶體資料庫)進行snapshot，

本文由mirson創作分享，如需進一步交流，請加QQ群：19310171或訪問www.softart.cn