一文徹底搞懂zookeeper核心知識點
初識 zookeeper
Zookeeper 它作為Hadoop項目中的一個開源子項目，是一個經典的分布式數據一致性解決方案，致力于為分布式應用提供一個高性能、高可用，且具有嚴格順序訪問控制能力的分布式協調服務。
1、zookeeper數據模型
zookeeper 維護了一個類似文件系統的數據結構，每個子目錄（/微信、/微信/公眾號）都被稱作為 znode 即節點。和文件系統一樣，我們可以很輕松的對 znode 節點進行增加、刪除等操作，而且還可以在一個znode下增加、刪除子znode，區別在于文件系統的是，znode可以存儲數據（嚴格說是必須存放數據，默認是個空字符）。
由于zookeeper是目錄節點結構，在獲取和創建節點時，必須要以“/” 開頭，否則在獲取節點時會報錯 Path must start with / character。
- [zk: localhost:2181(CONNECTED) 13] get test
- Command failed: java.lang.IllegalArgumentException: Path must start with / character
根節點名必須為“/XXX”，創建子節點時必須要帶上根節點目錄“/XXX/CCC”、“/XXX/AAA”。
例如：想要獲取下圖 程序員內點事 節點必須拼接完整的路徑 get /微信/公眾號/程序員內點事
get /微信/公眾號/程序員內點事
在這里插入圖片描述
znode被用來存儲 byte級 或 kb級 的數據，可存儲的最大數據量是1MB（請注意：一個節點的數據量不僅包含它自身存儲數據，它的所有子節點的名字也要折算成Byte數計入，因此znode的子節點數也不是無限的）雖然可以手動的修改節點存儲量大小，但一般情況下并不推薦這樣做。
2、znode節點屬性
一個znode節點不僅可以存儲數據，還有一些其他特別的屬性。接下來我們創建一個/test節點分析一下它各個屬性的含義。
- [zk: localhost:2181(CONNECTED) 6] get /test
- 456
- cZxid = 0x59ac //
- ctime = Mon Mar 30 15:20:08 CST 2020
- mZxid = 0x59ad
- mtime = Mon Mar 30 15:22:25 CST 2020
- pZxid = 0x59ac
- cversion = 0
- dataVersion = 2
- aclVersion = 0
- ephemeralOwner = 0x0
- dataLength = 3
- numChildren = 0
| 節點屬性 | 注解 |
|---|---|
| cZxid | 該數據節點被創建時的事務Id |
| mZxid | 該數據節點被修改時最新的事物Id |
| pZxid | 當前節點的父級節點事務Id |
| ctime | 該數據節點創建時間 |
| mtime | 該數據節點最后修改時間 |
| dataVersion | 當前節點版本號（每修改一次值+1遞增） |
| cversion | 子節點版本號（子節點修改次數，每修改一次值+1遞增） |
| aclVersion | 當前節點acl版本號（節點被修改acl權限，每修改一次值+1遞增） |
| ephemeralOwner | 臨時節點標示，當前節點如果是臨時節點，則存儲的創建者的會話id（sessionId），如果不是，那么值=0 |
| dataLength | 當前節點所存儲的數據長度 |
| numChildren | 當前節點下子節點的個數 |
我們看到一個znode節點的屬性比較多，但比較主要的屬性還是zxid、version、acl 這三個。
Zxid：
znode節點狀態改變會導致該節點收到一個zxid格式的時間戳，這個時間戳是全局有序的，znode節點的建立或者更新都會產生一個新的。如果zxid1的值 < zxid2的值，那么說明zxid2發生的改變在zxid1之后。每個znode節點都有3個zxid屬性，cZxid（節點創建時間）、mZxid（該節點修改時間，與子節點無關）、pZxid（該節點或者該節點的子節點的最后一次創建或者修改時間，孫子節點無關）。
zxid屬性主要應用于zookeeper的集群，這個后邊介紹集群時詳細說。
Version：
znode屬性中一共有三個版本號dataversion（數據版本號）、cversion（子節點版本號）、aclversion（節點所擁有的ACL權限版本號）。
znode中的數據可以有多個版本，如果某一個節點下存有多個數據版本，那么查詢這個節點數據就需要帶上版本號。每當我們對znode節點數據修改后，該節點的dataversion版本號會遞增。當客戶端請求該znode節點時，會同時返回節點數據和版本號。另外當dataversion為 -1的時候可以忽略版本進行操作。對一個節點設置權限時aclVersion版本號會遞增，下邊會詳細說ACL權限控制。
驗證一下，我們修改/test節點的數據看看dataVersion有什么變化，發現dataVersion屬性變成了 3，版本號遞增了。
- [zk: localhost:2181(CONNECTED) 10] set /test 8888
- cZxid = 0x59ac
- ctime = Mon Mar 30 15:20:08 CST 2020
- mZxid = 0x59b6
- mtime = Mon Mar 30 16:58:08 CST 2020
- pZxid = 0x59ac
- cversion = 0
- dataVersion = 3
- aclVersion = 0
- ephemeralOwner = 0x0
- dataLength = 4
- numChildren = 0
3、znode的類型
zookeeper 有四種類型的znode，在用客戶端 client 創建節點的時候需要指定類型。
- zookeeper.create("/公眾號/程序員內點事", "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
- PERSISTENT-持久化目錄節點 ：client創建節點后，與zookeeper斷開連接該節點將被持久化，當client再次連接后節點依舊存在。
- PERSISTENT_SEQUENTIAL-持久化順序節點 ：client創建節點后，與zookeeper斷開連接該節點將被持久化，再次連接節點還存在，zookeeper會給該節點名稱進行順序編號，例如：/lock/0000000001、/lock/0000000002、/lock/0000000003。
- EPHEMERAL-臨時目錄節點 ：client與zookeeper斷開連接后，該節點即會被刪除
- EPHEMERAL_SEQUENTIAL-臨時順序節點 ：client與zookeeper斷開連接后，該節點被刪除，會給該節點名稱進行順序編號，例如：/lock/0000000001、/lock/0000000002、/lock/0000000003。
節點的ACL權限控制
ACL：即 Access Control List (節點的權限控制)，通過ACL機制來解決znode節點的訪問權限問題，要注意的是zookeeper對權限的控制是基于znode級別的，也就說節點之間的權限不具有繼承性，即子節點不繼承父節點的權限。
zookeeper中設置ACL權限的格式由<schema>:<id>:<acl>三段組成。
schema ：表示授權的方式
- world：表示任何人都可以訪問
- auth：只有認證的用戶可以訪問
- digest：使用username ：password用戶密碼生成MD5哈希值作為認證ID
- host/ip：使用客戶端主機IP地址來進行認證
id：權限的作用域，用來標識身份，依賴于schema選擇哪種方式。
acl：給一個節點賦予哪些權限，節點的權限有create,、delete、write、read、admin 統稱 cdwra。
1、world：表示任何人都可以訪問
我們用 getAcl 命令來看一下，沒有設置過權限的znode節點，默認情況下的權限情況。
- [zk: localhost:2181(CONNECTED) 12] getAcl /test
- 'world,'anyone
- : cdrwa
看到沒有設置ACL屬性的節點，默認schema 使用的是world，作用域是anyone，節點權限是cdwra，也就是說任何人都可以訪問。
那我們如果要給一個schema 為非world的節點設置world權限咋搞？
- setAcl /test world:anyone:crdwa
2、auth：只有認證的用戶可以訪問
schema 用auth授權表示只有認證后的用戶才可以訪問，那么首先就需要添加認證用戶，添加完以后需要對認證的用戶設置ACL權限。
addauth digest test:password(明文)
需要注意的是設置認證用戶時的密碼是明文的。
- [zk: localhost:2181(CONNECTED) 2] addauth digest user:user //用戶名：密碼
- [zk: localhost:2181(CONNECTED) 5] setAcl /test auth:user:crdwa
- [zk: localhost:2181(CONNECTED) 6] getAcl /test
- 'digest,'user:ben+k/3JomjGj4mfd4fYsfM6p0A=
- : cdrwa
實際上我們這樣設置以后，就是將這個節點開放給所有認證的用戶，setAcl /test auth:user:crdwa 相當于setAcl /test auth::crdwa。
3、digest：用戶名:密碼的驗證方式
用戶名:密碼方式授權是針對單個特定用戶，這種方式是不需要先添加認證用戶的。
如果在代碼中使用zookeeper客戶端設置ACL，那么密碼是明文的，但若是zk.cli等客戶端操作就需要將密碼進行sha1及base64處理。
- setAcl <path> digest:<user>:<password(密文)>:<acl>
- setAcl /test digest:user:jalRr+knv/6L2uXdenC93dEDNuE=:crdwa
那么密碼如何加密嘞？有以下幾種方式：
通過shell命令加密
- echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64
使用zookeeper自帶的類庫org.apache.zookeeper.server.auth.DigestAuthenticationProvider生成
- java -cp /zookeeper-3.4.13/zookeeper-3.4.13.jar:/zookeeper-3.4.13/lib/slf4j-api-1.7.25.jar \
- org.apache.zookeeper.server.auth.DigestAuthenticationProvider \
- root:root
- root:root->root:qiTlqPLK7XM2ht3HMn02qRpkKIE=
4、host/ip：使用客戶端主機IP地址來進行認證
這種方式就比較好理解了，通過對特定的IP地址，也可以是一個IP段進行授權。
- [zk: localhost:2181(CONNECTED) 3] setAcl /test0000000014 ip:127.0.0.1:crdwa
- cZxid = 0x59ac
- ctime = Mon Mar 30 15:20:08 CST 2020
- mZxid = 0x59b6
- mtime = Mon Mar 30 16:58:08 CST 2020
- pZxid = 0x59ac
- cversion = 0
- dataVersion = 3
- aclVersion = 3 // 這個版本一直在增加
- ephemeralOwner = 0x0
- dataLength = 4
- numChildren = 0
zookeeper 靈魂 watcher
我們在開頭就說過：zookeeper可以為dubbo提供服務的注冊與發現，作為注冊中心，但你有想過zookeeper為啥能夠實現服務的注冊與發現嗎？這就不得不說一下zookeeper的靈魂 Watcher（監聽者）。
1、watcher是個啥？
watcher 是zooKeeper中一個非常核心功能 ，客戶端watcher 可以監控節點的數據變化以及它子節點的變化，一旦這些狀態發生變化，zooKeeper服務端就會通知所有在這個節點上設置過watcher的客戶端 ，從而每個客戶端都很快感知，它所監聽的節點狀態發生變化，而做出對應的邏輯處理。
簡單的介紹了一下watcher ，那么我們來分析一下，zookeeper是如何實現服務的注冊與發現。zookeeper的服務注冊與發現，主要應用的是zookeeper的znode節點數據模型和watcher機制，大致的流程如下：
在這里插入圖片描述
- 服務注冊： 服務提供者（Provider）啟動時，會向zookeeper服務端注冊服務信息，也就是創建一個節點，例如：用戶注冊服務com.xxx.user.register，并在節點上存儲服務的相關數據（如服務提供者的ip地址、端口等）。
- 服務發現： 服務消費者（Consumer）啟動時，根據自身配置的依賴服務信息，向zookeeper服務端獲取注冊的服務信息并設置watch監聽，獲取到注冊的服務信息之后，將服務提供者的信息緩存在本地，并進行服務的調用。
- 服務通知： 一旦服務提供者因某種原因宕機不再提供服務之后，客戶端與zookeeper服務端斷開連接，zookeeper服務端上服務提供者對應服務節點會被刪除（例如：用戶注冊服務com.xxx.user.register），隨后zookeeper服務端會異步向所有消費用戶注冊服務com.xxx.user.register，且設置了watch監聽的服務消費者發出節點被刪除的通知，消費者根據收到的通知拉取最新服務列表，更新本地緩存的服務列表。
上邊的過程就是zookeeper可以實現服務注冊與發現的大致原理。
2、watcher類型
znode節點可以設置兩類watch，一種是DataWatches，基于znode節點的數據變更從而觸發 watch 事件，觸發條件getData()、exists()、setData()、 create()。
另一種是Child Watches，基于znode的孩子節點發生變更觸發的watch事件，觸發條件 getChildren()、 create()。
而在調用 delete() 方法刪除znode時，則會同時觸發Data Watches和Child Watches，如果被刪除的節點還有父節點，則父節點會觸發一個Child Watches。
3、watcher特性
watch對節點的監聽事件是一次性的！客戶端在指定的節點設置了監聽watch，一旦該節點數據發生變更通知一次客戶端后，客戶端對該節點的監聽事件就失效了。
如果還要繼續監聽這個節點，就需要我們在客戶端的監聽回調中，再次對節點的監聽watch事件設置為True。否則客戶端只能接收到一次該節點的變更通知。
zookeeper 實現的功能
服務的注冊與發現功能只是zookeeper的冰山一角，它還能實現諸如分布式鎖、隊列、配置中心等一系列功能，接下來我們只分析一下原理，具體的實現大家上網查一下資料還是比較全的。
1、分布式鎖
zookeeper基于watcher機制和znode的有序節點，天生就是一個分布式鎖的坯子。首先創建一個/test/lock父節點作為一把鎖，盡量是持久節點（PERSISTENT類型），每個嘗試獲取這把鎖的客戶端，在/test/lock父節點下創建臨時順序子節點。
由于序號的遞增性，我們規定序號最小的節點即獲得鎖。例如：客戶端來獲取鎖，在/test/lock節點下創建節點為/test/lock/seq-00000001，它是最小的所以它優先拿到了鎖，其它節點等待通知再次獲取鎖。/test/lock/seq-00000001執行完自己的邏輯后刪除節點釋放鎖。
那么節點/test/lock/seq-00000002想要獲取鎖等誰的通知呢？
這里我們讓/test/lock/seq-00000002節點監聽/test/lock/seq-00000001節點，一旦/test/lock/seq-00000001節點刪除，則通知/test/lock/seq-00000002節點，讓它再次判斷自己是不是最小的節點，是則拿到鎖，不是繼續等通知。
以此類推/test/lock/seq-00000003節點監聽/test/lock/seq-00000002節點，總是讓后一個節點監聽前一個節點，不用讓所有節點都監聽最小的節點，避免設置不必要的監聽，以免造成大量無效的通知，形成“羊群效應”。
zookeeper分布式鎖和redis分布式鎖相比，因為大量的創建、刪除節點性能上比較差，并不是很推薦。
2、分布式隊列
zookeeper實現分布式隊列也很簡單，應用znode的有序節點天然的“先進先出”，后創建的節點總是最大的，出隊總是拿序號最小的節點即可。
3、配置管理
現在有很多開源項目都在使用Zookeeper來維護配置，像消息隊列Kafka中，就使用Zookeeper來維護broker的信息；dubbo中管理服務的配置信息。原理也是基于watcher機制，例如：創建一個/config節點存放一些配置，客戶端監聽這個節點，一點修改/config節點的配置信息，通知各個客戶端數據變更重新拉取配置信息。
4、命名服務
zookeeper的命名服務：也就是我們常說的服務注冊與發現，主要是根據指定名字來獲取資源或服務的地址，服務提供者等信息，利用其znode節點的特點和watcher機制，將其作為動態注冊和獲取服務信息的配置中心，統一管理服務名稱和其對應的服務器列表信息，我們能夠近乎實時地感知到后端服務器的狀態(上線、下線、宕機)。
