Zookeeper的典型應用場景(轉)

2019 年 10 月 8 日
筆記

在寒假前，完成了Zookeeper系列的前5篇文章，主要是分散式的相關理論，包括CAP，BASE理論，分散式數據一致性演算法：2PC，3PC，Paxos演算法，Zookeeper的相關基本特性，ZAB協議。今天，完成Zookeeper系列的最後一篇也是最為重要的內容：Zookeeper的典型應用場景的介紹，我們只有知道zk怎麼用，用在哪，我們才能真正掌握Zookeeper這個優秀的分散式協調框架。

首先，我們要知道，Zookeeper是一個具有高可用、高性能和具有分散式數據一致性的分散式數據管理及協調框架，是基於對ZAB演算法的實現，基於這樣的特性，使ZK成為解決分散式一致性問題的利器，同時Zookeeper提供了豐富的節點類型和Watcher監聽機制，通過這兩個特點，可以非常方便的構建一系列分散式系統中都會涉及的核心功能：如：數據發布/訂閱，負載均衡，命名服務，分散式協調/通知，集群管理，Master選舉，分散式鎖，分散式隊列等。這一篇，將針對這些分散式應用場景來做介紹，並介紹Zookeeper在現在的大型分散式系統中的作為核心組件的實際應用。

數據發布與訂閱（配置中心）

數據發布/訂閱系統，即配置中心。需要發布者將數據發布到Zookeeper的節點上，供訂閱者進行數據訂閱，進而達到動態獲取數據的目的，實現配置資訊的集中式管理和數據的動態更新（可以把我們知道RPC的註冊中心看成是此場景的應用）。

發布/訂閱一般有兩種設計模式：推模式和拉模式，服務端主動將數據更新發送給所有訂閱的客戶端稱為推模式；客戶端主動請求獲取最新數據稱為拉模式，Zookeeper採用了推拉相結合的模式，客戶端向服務端註冊自己需要關注的節點，一旦該節點數據發生變更，那麼服務端就會向相應的客戶端推送Watcher事件通知，客戶端接收到此通知後，主動到服務端獲取最新的數據。

　若將配置資訊存放到Zookeeper上進行集中管理，在通常情況下，應用在啟動時會主動到Zookeeper服務端上進行一次配置資訊的獲取，同時，在指定節點上註冊一個Watcher監聽，這樣在配置資訊發生變更，服務端都會實時通知所有訂閱的客戶端，從而達到實時獲取最新配置的目的。

注意：對於像Dubbo這樣的RPC框架來說，zk將作為其註冊中心，客戶端第一次通過向zk集群獲得服務的地址，然後會存儲在本地，下一次進行調用時就不會再次去zk集群中查詢，而是直接使用本地存儲的地址，只有當服務地址變更時，才會通知客戶端再次獲取。

在平時的開發中，經常會碰到這樣的需求：系統中需要使用一些通用的配置資訊，例如：機器列表資訊，資料庫的配置資訊（比如：要實現資料庫的切換的應用場景），運行時的開關配置等。這些全局配置資訊通常有3個特性：數據量通常比較小；數據內容在運行時會發生動態變化；集群中各機器共享、配置一致。假設，我們的集群規模很大，且配置資訊經常變更，所以通過存儲本地配置文件或記憶體變數的形式實現都很困難，所以我們使用zk來做一個全局配置資訊的管理。

負載均衡

負載均衡是一種相當常見的電腦網路技術，用來對多個電腦、網路連接、CPU、磁碟驅動或其他資源進行分配負載，以達到優化資源使用、最大化吞吐率、最小化響應時間和避免過載的目的。通常負載均衡可以分為硬體（F5）和軟體(Nginx)負載均衡兩類。Zookeeper也可以作為實現軟負載均衡的一種方式。

分散式系統為了保證可用性，通常通過副本的方式來對數據和服務進行部署，而對於客戶端吧來說，只需要在這樣對等的服務提供方式中選擇一個來執行相關的業務邏輯，怎麼選，這就是負載均衡的應用。

比如，典型的需要負載均衡的DNS（Domain Name System）服務,我們可以用zookeeper實現動態的DNS方案，可以參考《從Paxos到Zookeeper》這本書對於用zk實現動態DNS的方案P167。

zk實現負載均衡就是通過watcher機制和臨時節點判斷哪些節點宕機來獲得可用的節點實現的：

ZooKeeper會維護一個樹形的數據結構，類似於Windows資源管理器目錄，其中EPHEMERAL類型的節點會隨著創建它的客戶端斷開而被刪除，利用這個特性很容易實現軟負載均衡。

基本原理是，每個應用的Server啟動時創建一個EPHEMERAL節點，應用客戶端通過讀取節點列表獲得可用伺服器列表，並訂閱節點事件，有Server宕機斷開時觸發事件，客戶端監測到後把該Server從可用列表中刪除。

消息中間件中發布者和訂閱者的負載均衡，linkedin開源的KafkaMQ和阿里開源的MetaQ都是通過zookeeper來做到生產者、消費者的負載均衡。

命名服務

命名服務是分步實現系統中較為常見的一類場景，分散式系統中，被命名的實體通常可以是集群中的機器、提供的服務地址或遠程對象等，通過命名服務，客戶端可以根據指定名字來獲取資源的實體、服務地址和提供者的資訊，最常見的就是RPC 框架的服務地址列表的命名。Zookeeper也可幫助應用系統通過資源引用的方式來實現對資源的定位和使用，廣義上的命名服務的資源定位都不是真正意義上的實體資源，在分散式環境中，上層應用僅僅需要一個全局唯一的名字。Zookeeper可以實現一套分散式全局唯一ID的分配機制。（用UUID的方式的問題在於生成的字元串過長，浪費存儲空間且字元串無規律不利於開發調試）通過調用Zookeeper節點創建的API介面就可以創建一個順序節點，並且在API返回值中會返回這個節點的完整名字，利用此特性，可以生成全局ID，其步驟如下

　　1. 客戶端根據任務類型，在指定類型的任務下通過調用介面創建一個順序節點，如"job-"。

　　2. 創建完成後，會返回一個完整的節點名，如"job-00000001"。

　　3. 客戶端拼接type類型和返回值後，就可以作為全局唯一ID了，如"type2-job-00000001"。

阿里巴巴集團開源的分散式服務框架Dubbo中使用ZooKeeper來作為其命名服務，維護全局的服務地址列表。在Dubbo實現中：

服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發布。

服務消費者啟動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址，並向/dubbo/${serviceName}/consumers目錄下寫入自己的URL地址。

注意，所有向ZK上註冊的地址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的資訊。

分散式協調/通知.

Zookeeper中特有的Watcher註冊於非同步通知機制，能夠很好地實現分散式環境下不同機器，甚至不同系統之間的協調與通知，從而實現對數據變更的實時處理。通常的做法是不同的客戶端都對Zookeeper上的同一個數據節點進行Watcher註冊，監聽數據節點的變化（包括節點本身和子節點），若數據節點發生變化，那麼所有訂閱的客戶端都能夠接收到相應的Watcher通知，並作出相應處理。在絕大多數分散式系統中，系統機器間的通訊無外乎心跳檢測、工作進度彙報和系統調度。這三種類型的機器通訊方式都可以使用zookeeper來實現：

　　① 心跳檢測，不同機器間需要檢測到彼此是否在正常運行，可以使用Zookeeper實現機器間的心跳檢測，基於其臨時節點特性（臨時節點的生存周期是客戶端會話，客戶端若當即後，其臨時節點自然不再存在），可以讓不同機器都在Zookeeper的一個指定節點下創建臨時子節點，不同的機器之間可以根據這個臨時子節點來判斷對應的客戶端機器是否存活。通過Zookeeper可以大大減少系統耦合。

　　② 工作進度彙報，通常任務被分發到不同機器後，需要實時地將自己的任務執行進度彙報給分發系統，可以在Zookeeper上選擇一個節點，每個任務客戶端都在這個節點下面創建臨時子節點，這樣不僅可以判斷機器是否存活，同時各個機器可以將自己的任務執行進度寫到該臨時節點中去，以便中心系統能夠實時獲取任務的執行進度。

　　③ 系統調度，Zookeeper能夠實現如下系統調度模式：分散式系統由控制台和一些客戶端系統兩部分構成，控制台的職責就是需要將一些指令資訊發送給所有的客戶端，以控制他們進行相應的業務邏輯，後台管理人員在控制台上做一些操作，實際上就是修改Zookeeper上某些節點的數據，Zookeeper可以把數據變更以時間通知的形式發送給訂閱客戶端。

集群管理

Zookeeper的兩大特性（節點特性和watcher機制）：

　　· 客戶端如果對Zookeeper的數據節點註冊Watcher監聽，那麼當該數據及誒單內容或是其子節點列表發生變更時，Zookeeper伺服器就會向訂閱的客戶端發送變更通知。

　　· 對在Zookeeper上創建的臨時節點，一旦客戶端與伺服器之間的會話失效，那麼臨時節點也會被自動刪除。

機器在線率有較高要求的場景，能夠快速對集群中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測集群機器是否存活。過去的做法通常是：監控系統通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統彙報「我還活著」。這種做法可行，但是存在兩個比較明顯的問題：

1. 集群中機器有變動的時候，牽連修改的東西比較多。

2. 有一定的延時。

利用ZooKeeper有兩個特性，就可以實時另一種集群機器存活性監控系統。可以實現集群機器存活監控系統，若監控系統在/clusterServers節點上註冊一個Watcher監聽，那麼但凡進行動態添加機器的操作，就會在/clusterServers節點下創建一個臨時節點：/clusterServers/[Hostname]，這樣，監控系統就能夠實時監測機器的變動情況。下面通過分散式日誌收集系統的典型應用來學習Zookeeper如何實現集群管理。

　　分散式日誌收集系統的核心工作就是收集分布在不同機器上的系統日誌，在典型的日誌系統架構設計中，整個日誌系統會把所有需要收集的日誌機器分為多個組別，每個組別對應一個收集器，這個收集器其實就是一個後台機器，用於收集日誌，對於大規模的分散式日誌收集系統場景，通常需要解決兩個問題：

　　· 變化的日誌源機器

　　· 變化的收集器機器

　　無論是日誌源機器還是收集器機器的變更，最終都可以歸結為如何快速、合理、動態地為每個收集器分配對應的日誌源機器。

① 註冊收集器機器，在Zookeeper上創建一個節點作為收集器的根節點，例如/logs/collector的收集器節點，每個收集器機器啟動時都會在收集器節點下創建自己的節點，如/logs/collector/[Hostname]

② 任務分發，所有收集器機器都創建完對應節點後，系統根據收集器節點下子節點的個數，將所有日誌源機器分成對應的若干組，然後將分組後的機器列表分別寫到這些收集器機器創建的子節點，如/logs/collector/host1（持久節點）上去。這樣，收集器機器就能夠根據自己對應的收集器節點上獲取日誌源機器列表，進而開始進行日誌收集工作。

③ 狀態彙報，完成任務分發後，機器隨時會宕機，所以需要有一個收集器的狀態彙報機制，每個收集器機器上創建完節點後，還需要再對應子節點上創建一個狀態子節點，如/logs/collector/host/status（臨時節點），每個收集器機器都需要定期向該結點寫入自己的狀態資訊，這可看做是心跳檢測機制，通常收集器機器都會寫入日誌收集狀態資訊，日誌系統通過判斷狀態子節點最後的更新時間來確定收集器機器是否存活。

④ 動態分配，若收集器機器宕機，則需要動態進行收集任務的分配，收集系統運行過程中關注/logs/collector節點下所有子節點的變更，一旦有機器停止彙報或有新機器加入，就開始進行任務的重新分配，此時通常由兩種做法：

　 · 全局動態分配，當收集器機器宕機或有新的機器加入，系統根據新的收集器機器列表，立即對所有的日誌源機器重新進行一次分組，然後將其分配給剩下的收集器機器。

　　· 局部動態分配，每個收集器機器在彙報自己日誌收集狀態的同時，也會把自己的負載彙報上去，如果一個機器宕機了，那麼日誌系統就會把之前分配給這個機器的任務重新分配到那些負載較低的機器，同樣，如果有新機器加入，會從那些負載高的機器上轉移一部分任務給新機器。

Master選舉

　　在分散式系統中，Master往往用來協調集群中其他系統單元，具有對分散式系統狀態變更的決定權，如在讀寫分離的應用場景中，客戶端的寫請求往往是由Master來處理，或者其常常處理一些複雜的邏輯並將處理結果同步給其他系統單元。利用Zookeeper的一致性，能夠很好地保證在分散式高並發情況下節點的創建一定能夠保證全局唯一性，即Zookeeper將會保證客戶端無法重複創建一個已經存在的數據節點（由其分散式數據的一致性保證）。

首先創建/master_election/2016-11-12節點，客戶端集群每天會定時往該節點下創建臨時節點，如/master_election/2016-11-12/binding，這個過程中，只有一個客戶端能夠成功創建，此時其變成master，其他節點都會在節點/master_election/2016-11-12上註冊一個子節點變更的Watcher，用於監控當前的Master機器是否存活，一旦發現當前Master掛了，其餘客戶端將會重新進行Master選舉。

另外，這種場景演化一下，就是動態Master選舉。這就要用到?EPHEMERAL_SEQUENTIAL類型節點的特性了。

上文中提到，所有客戶端創建請求，最終只有一個能夠創建成功。在這裡稍微變化下，就是允許所有請求都能夠創建成功，但是得有個創建順序，於是所有的請求最終在ZK上創建結果的一種可能情況是這樣：/currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2,?/currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個機器作為Master，如果這個機器掛了，由於他創建的節點會馬上小時，那麼之後最小的那個機器就是Master了。

其在實際中應用有： · 在搜索系統中，如果集群中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引數據一致。因此讓集群中的Master來進行全量索引的生成，然後同步到集群中其它機器。另外，Master選舉的容災措施是，可以隨時進行手動指定master，就是說應用在zk在無法獲取master資訊時，可以通過比如http方式，向一個地方獲取master。

在Hbase中，也是使用ZooKeeper來實現動態HMaster的選舉。在Hbase實現中，會在ZK上存儲一些ROOT表的地址和 HMaster的地址，HRegionServer也會把自己以臨時節點（Ephemeral）的方式註冊到Zookeeper中，使得HMaster可以隨時感知到各個HRegionServer的存活狀態，同時，一旦HMaster出現問題，會重新選舉出一個HMaster來運行，從而避免了 HMaster的單點問題。

分散式鎖

分散式鎖用於控制分散式系統之間同步訪問共享資源的一種方式，可以保證不同系統訪問一個或一組資源時的一致性，主要分為排它鎖和共享鎖。排它鎖又稱為寫鎖或獨佔鎖，若事務T1對數據對象O1加上了排它鎖，那麼在整個加鎖期間，只允許事務T1對O1進行讀取和更新操作，其他任何事務都不能再對這個數據對象進行任何類型的操作，直到T1釋放了排它鎖。

① 獲取鎖，在需要獲取排它鎖時，所有客戶端通過調用介面，在/exclusive_lock節點下創建臨時子節點/exclusive_lock/lock。Zookeeper可以保證只有一個客戶端能夠創建成功，沒有成功的客戶端需要註冊/exclusive_lock節點監聽。

② 釋放鎖，當獲取鎖的客戶端宕機或者正常完成業務邏輯都會導致臨時節點的刪除，此時，所有在/exclusive_lock節點上註冊監聽的客戶端都會收到通知，可以重新發起分散式鎖獲取。

　共享鎖又稱為讀鎖，若事務T1對數據對象O1加上共享鎖，那麼當前事務只能對O1進行讀取操作，其他事務也只能對這個數據對象加共享鎖，直到該數據對象上的所有共享鎖都被釋放。（控制時序）

　　① 獲取鎖，在需要獲取共享鎖時，所有客戶端都會到/shared_lock下面創建一個臨時順序節點，如果是讀請求，那麼就創建例如/shared_lock/host1-R-00000001的節點，如果是寫請求，那麼就創建例如/shared_lock/host2-W-00000002的節點。

　　② 判斷讀寫順序，不同事務可以同時對一個數據對象進行讀寫操作，而更新操作必須在當前沒有任何事務進行讀寫情況下進行，通過Zookeeper來確定分散式讀寫順序，大致分為四步。

　　　　1. 創建完節點後，獲取/shared_lock節點下所有子節點，並對該節點變更註冊監聽。

　　　　2. 確定自己的節點序號在所有子節點中的順序。

　　　　3. 對於讀請求：若沒有比自己序號小的子節點或所有比自己序號小的子節點都是讀請求，那麼表明自己已經成功獲取到共享鎖，同時開始執行讀取邏輯，若有寫請求，則需要等待。對於寫請求：若自己不是序號最小的子節點，那麼需要等待。

　　　　4. 接收到Watcher通知後，重複步驟1。

　　③ 釋放鎖，其釋放鎖的流程與獨佔鎖一致。

上述共享鎖的實現方案，可以滿足一般分散式集群競爭鎖的需求，但是如果機器規模擴大會出現一些問題，下面著重分析判斷讀寫順序的步驟3。　　針對如上圖所示的情況進行分析

　　1. host1首先進行讀操作，完成後將節點/shared_lock/host1-R-00000001刪除。

　　2. 餘下4台機器均收到這個節點移除的通知，然後重新從/shared_lock節點上獲取一份新的子節點列表。

　　3. 每台機器判斷自己的讀寫順序，其中host2檢測到自己序號最小，於是進行寫操作，餘下的機器則繼續等待。

　　4. 繼續…

　　可以看到，host1客戶端在移除自己的共享鎖後，Zookeeper發送了子節點更變Watcher通知給所有機器，然而除了給host2產生影響外，對其他機器沒有任何作用。大量的Watcher通知和子節點列表獲取兩個操作會重複運行，這樣會造成系能鞥影響和網路開銷，更為嚴重的是，如果同一時間有多個節點對應的客戶端完成事務或事務中斷引起節點小時，Zookeeper伺服器就會在短時間內向其他所有客戶端發送大量的事件通知，這就是所謂的羊群效應。

　可以有如下改動來避免羊群效應。

　　1. 客戶端調用create介面常見類似於/shared_lock/[Hostname]-請求類型-序號的臨時順序節點。

　　2. 客戶端調用getChildren介面獲取所有已經創建的子節點列表（不註冊任何Watcher）。

　　3. 如果無法獲取共享鎖，就調用exist介面來對比自己小的節點註冊Watcher。對於讀請求：向比自己序號小的最後一個寫請求節點註冊Watcher監聽。對於寫請求：向比自己序號小的最後一個節點註冊Watcher監聽。

　　4. 等待Watcher通知，繼續進入步驟2。

　　此方案改動主要在於：每個鎖競爭者，只需要關注/shared_lock節點下序號比自己小的那個節點是否存在即可。

分散式隊列

分散式隊列可以簡單分為先入先出隊列模型和等待隊列元素聚集後統一安排處理執行的Barrier模型。

① FIFO先入先出，先進入隊列的請求操作先完成後，才會開始處理後面的請求。FIFO隊列就類似於全寫的共享模型，所有客戶端都會到/queue_fifo這個節點下創建一個臨時節點，如/queue_fifo/host1-00000001。

創建完節點後，按照如下步驟執行。

　　1. 通過調用getChildren介面來獲取/queue_fifo節點的所有子節點，即獲取隊列中所有的元素。

　　2. 確定自己的節點序號在所有子節點中的順序。

　　3. 如果自己的序號不是最小，那麼需要等待，同時向比自己序號小的最後一個節點註冊Watcher監聽。

　　4. 接收到Watcher通知後，重複步驟1。

② Barrier分散式屏障，最終的合併計算需要基於很多並行計算的子結果來進行，開始時，/queue_barrier節點已經默認存在，並且將結點數據內容賦值為數字n來代表Barrier值，之後，所有客戶端都會到/queue_barrier節點下創建一個臨時節點，例如/queue_barrier/host1。　創建完節點後，按照如下步驟執行。

　　1. 通過調用getData介面獲取/queue_barrier節點的數據內容，如10。

　　2. 通過調用getChildren介面獲取/queue_barrier節點下的所有子節點，同時註冊對子節點變更的Watcher監聽。

　　3. 統計子節點的個數。

　　4. 如果子節點個數還不足10個，那麼需要等待。

　　5. 接受到Wacher通知後，重複步驟3

上邊我們介紹了Zookeeper的典型的應用場景。zookeeper已經被廣泛應用于越來越多的大型分散式系統中了，其中包括：Dubbo的註冊中心，HDFS的namenode和YARN框架的ResourceManager的HA（用zookeeper解決單點問題實現HA），HBase，Kafka等大數據和分散式系統框架中。我們可以學習這些內容時，注意一下Zookeeper的具體的應用實現。