一、什么是zookeeper
ZooKeeper是一個分布式的，開放原始碼的分布式應用程式協調服務，是Google的Chubby一個開源的實作，是Hadoop和Hbase的重要組件，它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分布式同步、組服務等，
簡單來說，zookeeper = 檔案系統 + 監聽通知機制
二、檔案系統
zookeeper有著與linux類似的檔案系統，區別是，linux的目錄就是目錄，檔案就是檔案，而zookeeper中只有一個znode概念，本身可以做為“檔案”存盤一定的資料，又可以做為“目錄”存在，
/* +---+ |/ | +-+-+ | | +------+ +--|config| | +--+---+ | | +-----+ | +-----|ip | | | +-----+ | | +-----+ | +-----|port | | +-----+ | | +------+ +--|apps | +--+---+ | +-----+ +-----|app1 | | +-----+ | +-----+ +-----|app2 | +-----+ */
znode共分為四種：
1、PERSISTENT-持久化目錄節點
此節點在客戶端與zookeeper斷開連接之后，依然存在，需要主動洗掉，
2、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點
同樣地，此類節點也是需要主動洗掉，不會隨著客戶端的斷開連接而洗掉，與PERSISTENT不同的是，zookeeper會給此類節點進行編號，如：app0000003362，0000003362為zookeeper給的編號，自動遞增，由于此編號是一個有符號整形（4位元組），當它超過2147483647時，將會溢位，
3、EPHEMERAL-臨時目錄節點
與PERSISTENT不同的是，此類節點會在客戶端與zookeeper斷開連接之后被洗掉，由于其生命周期與連接有關，所以其不可以有子節點，
4、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點
與PERSISTENT_SEQUENTIAL類似擁有zookeeper的自動編號，區別是會在客戶端與zookeeper斷開連接之后被洗掉，且不可以有子節點，
值得注意的是，同路徑下，同名znode只能被創建一次，且每個znode最多只可以存盤1M資料，
三、監聽通知機制
客戶端注冊監聽它關心的目錄節點，當目錄節點發生變化（資料改變、被洗掉、子目錄節點增加洗掉）時，zookeeper會通知客戶端，
四、 實際應用
基于檔案系統與監聽通知機制，zookeeper有諸多應用場景，
1、命名服務（基于檔案系統）
名稱在所有計算機系統中起著重要的作用，它們用來共享資源，唯一標識物體，指向位置等，命名的物件可以有多種型別，而且可被一些不同的服務來訪問，命名服務器可根據給定的名字來進行資源或物件的地址定位，并獲取有關的屬性資訊，（百度百科）
簡單來說，就是通過名字來獲取對應資源/服務地址，利用znode的唯一性，可以創建一個全域節點，將對應的資訊記錄在znode中，需要使用對應資源的服務直接獲取此節點的資訊即可，
2、配置管理（基于檔案系統與監聽通知機制）
服務有自己的配置，而同一個服務可多點部署，如果采用組態檔的形式，在修改配置的時候，需要同步檔案至所有機器，再通知程度動態加載，或者直接重啟，若存在這種情況，整個后臺存在一份共享配置（路由資訊等），而在一次修改中，只需要同步到某個服務（擴容、增加下游節點等），長久之后，會出現不同服務的配置不同的情況（雖然對于他們自己所使用的部門是最新的），此時可以通過配置中心來解決此類問題，所有配置都從配置中心中讀取，統一管理，
自己實作配置中心畢竟是有代價，而利用zookeeper，完全可以實作配置中心的功能，將對應資訊存盤到對應的znode中，服務只需要監聽自己關心的配置（znode），一旦znode發生變化，利用watcher通知所有監聽此znode的客戶端（對于zookeeper而言，服務是他的客戶端），從而更新配置，
3、集群管理（基于檔案系統與監聽通知機制）
當一個服務部署成集群的時候，就會有兩個問題：機器的加入與退出，master的選舉，可以在zookeeper里創建一個持久化znode A，然后讓本集群所有的服務在A下創建臨時znode B，需要知道此集群的服務監聽A，當新機器加入時，創建新的B，舊機器離開（宕機、縮容等）時，自動洗掉B，不管是創建，還是洗掉，A都發生了變化，利用watcher通知所有監聽者，于是大家都知道本集群的情況了，
對于master選舉，同樣也可以在zookeeper里創建一個持久化znode C，而后所有服務在C里創建臨時順序編號目錄節點，每次選擇編號最大或者最小的做為master，由于臨時順序編號目錄節點的編號是自增的，若選擇最大的做為master，當有新機器加入時，新機器就會成為master，而選擇最小編號做為master，只要其不退出（znode沒刪），就不會產生切換master的情況，對資料來說是最安全的，
4、分布式鎖（基于檔案系統與監聽通知機制）
有一個程式，有兩個執行緒，都對相同變數進行100w次++操作，未加鎖的情況下，得到的結果并不是200w，同樣，在一個集群中，如果同時修改相同資源，也會出現相互覆寫的情況，此時，需要使用到分布式鎖來處理此類問題，要開始修改此資源之前，先獲取鎖，獲取成功之后才可以進行修改操作，由于zookeeper中，znode的唯一性，可以利用它來實作分布式鎖服務，需要獲取鎖時，在指定路徑下創建znode（非自動編號），需要釋放時，洗掉此znode，若創建失敗，則認為當前已有其它服務搶到了鎖，
若創建的是非自動編號的znode，會有一個問題，每次都是集群中所有服務競爭同一把鎖，會出現一個服務搶到多次，而其它服務一次都不成功的情況，此時可以將其修改為自動編號的znode，并監聽對應父znode，每次需要鎖時，創建一個自動編號的znode，若自己創建的znode在所有znode中編號最小，則認為自己搶到了鎖，解鎖（洗掉znode）之后，又會通知整個集群，這樣不僅實作了分布式鎖，而且人人有份，有序進行，
五、參考鏈接
https://blog.csdn.net/u010963948/article/details/83381757
https://www.cnblogs.com/lfs2640666960/p/11104838.html
https://blog.csdn.net/java_66666/article/details/81015302
https://blog.csdn.net/chunqiu3351/article/details/100762270
https://www.jianshu.com/p/d4fb16fafc2e
http://zookeeper.apache.org/doc/r3.3.3/zookeeperProgrammers.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/79517.html
標籤：其他