【分佈式】Zookeeper應用場景

1、前言

　　在上一篇博客已經介紹了Zookeeper開源客戶端的簡單實用，本篇講解Zookeeper的應用場景。

2、典型應用場景

　　Zookeeper是一個高可用的分佈式數據管理和協調框架，而且可以很好的保證分佈式環境中數據的一致性。在愈來愈多的分佈式系統（Hadoop、HBase、Kafka）中，Zookeeper都做爲核心組件使用。

　　2.1 數據發佈/訂閱

　　數據發佈/訂閱系統，即配置中心。須要發佈者將數據發佈到Zookeeper的節點上，供訂閱者進行數據訂閱，進而達到動態獲取數據的目的，實現配置信息的集中式管理和數據的動態更新。發佈/訂閱通常有兩種設計模式：推模式和拉模式，服務端主動將數據更新發送給全部訂閱的客戶端稱爲推模式；客戶端主動請求獲取最新數據稱爲拉模式，Zookeeper採用了推拉相結合的模式，客戶端向服務端註冊本身須要關注的節點，一旦該節點數據發生變動，那麼服務端就會向相應的客戶端推送Watcher事件通知，客戶端接收到此通知後，主動到服務端獲取最新的數據。

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

　　2.2 負載均衡

　　負載均衡是一種至關常見的計算機網絡技術，用來對多個計算機、網絡鏈接、CPU、磁盤驅動或其餘資源進行分配負載，以達到優化資源使用、最大化吞吐率、最小化響應時間和避免過載的目的。

　　使用Zookeeper實現動態DNS服務

　　· 域名配置，首先在Zookeeper上建立一個節點來進行域名配置，如DDNS/app1/server.app1.company1.com。

　　· 域名解析，應用首先從域名節點中獲取IP地址和端口的配置，進行自行解析。同時，應用程序還會在域名節點上註冊一個數據變動Watcher監聽，以便及時收到域名變動的通知。

　　· 域名變動，若發生IP或端口號變動，此時須要進行域名變動操做，此時，只須要對指定的域名節點進行更新操做，Zookeeper就會向訂閱的客戶端發送這個事件通知，客戶端以後就再次進行域名配置的獲取。

　　2.3 命名服務

　　命名服務是分步實現系統中較爲常見的一類場景，分佈式系統中，被命名的實體一般能夠是集羣中的機器、提供的服務地址或遠程對象等，經過命名服務，客戶端能夠根據指定名字來獲取資源的實體、服務地址和提供者的信息。Zookeeper也可幫助應用系統經過資源引用的方式來實現對資源的定位和使用，廣義上的命名服務的資源定位都不是真正意義上的實體資源，在分佈式環境中，上層應用僅僅須要一個全局惟一的名字。Zookeeper能夠實現一套分佈式全局惟一ID的分配機制。

　　經過調用Zookeeper節點建立的API接口就能夠建立一個順序節點，而且在API返回值中會返回這個節點的完整名字，利用此特性，能夠生成全局ID，其步驟以下

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

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

　　3. 客戶端拼接type類型和返回值後，就能夠做爲全局惟一ID了，如"type2-job-00000001"。

　　2.4 分佈式協調/通知

　　Zookeeper中特有的Watcher註冊於異步通知機制，可以很好地實現分佈式環境下不一樣機器，甚至不一樣系統之間的協調與通知，從而實現對數據變動的實時處理。一般的作法是不一樣的客戶端都對Zookeeper上的同一個數據節點進行Watcher註冊，監聽數據節點的變化（包括節點自己和子節點），若數據節點發生變化，那麼全部訂閱的客戶端都可以接收到相應的Watcher通知，並做出相應處理。

　　MySQL數據複製總線是一個實時的數據複製框架，用於在不一樣的MySQL數據庫實例之間進行異步數據複製和數據變化通知，整個系統由MySQL數據庫集羣、消息隊列系統、任務管理監控平臺、Zookeeper集羣等組件共同構成的一個包含生產者、複製管道、數據消費等部分的數據總線系統。

　　Zookeeper主要負責進行分佈式協調工做，在具體的實現上，根據功能將數據複製組件劃分爲三個模塊：Core（實現數據複製核心邏輯，將數據複製封裝成管道，並抽象出生產者和消費者概念）、Server（啓動和中止複製任務）、Monitor（監控任務的運行狀態，若數據複製期間發生異常或出現故障則進行告警）

　　每一個模塊做爲獨立的進程運行在服務端，運行時的數據和配置信息均保存在Zookeeper上。

　　① 任務建立，Core進程啓動時，首先向/mysql_replicator/tasks節點註冊任務，如建立一個子節點/mysql_replicator/tasks/copy_hot/item，若註冊過程當中發現該子節點已經存在，說明已經有其餘Task機器註冊了該任務，所以其自身不須要再建立該節點。

　　② 任務熱備份，爲了應對任務故障或者複製任務所在主機故障，複製組件採用"熱備份"的容災方式，即將同一個複製任務部署在不一樣的主機上，主備任務機經過Zookeeper互相檢測運行監控情況。不管在第一步是否建立了任務節點，每臺機器都須要在/mysql_replicator/tasks/copy_hot_item/instrances節點上將本身的主機名註冊上去，節點類型爲臨時順序節點，在完成子節點建立後，天天任務機器均可以獲取到本身建立的節點名及全部子節點列表，而後經過對比判斷本身是不是全部子節點中序號最小的，如果，則將本身運行狀態設置爲RUNNING，其餘機器設置爲STANDBY，這種策略稱爲小序號優先策略。

　　③ 熱備切換，完成運行狀態的標示後，其中標記爲RUNNING的客戶端機器進行正常的數據複製，而標記爲STANDBY的機器則進入待命狀態，一旦RUNNING機器出現故障，那麼全部標記爲STANDBY的機器再次按照小序號優先策略來選出RUNNIG機器運行（STANDY機器須要在/mysql_replicator/tasks/copy_hot_item/instances節點上註冊一個子節點列表變動監聽，RUNNING機器宕機與Zookeeper斷開鏈接後，對應的節點也會消失，因而全部客戶端收到通知，進行新一輪選舉）。

　　④ 記錄執行狀態，RUNNING機器須要將運行時的上下文狀態保留給STANDBY機器。

　　⑤ 控制檯協調，Server的主要工做就是進行任務控制，經過Zookeeper來對不一樣任務進行控制和協調，Server會將每一個複製任務對應生產者的元數據及消費者的相關信息以配置的形式寫入任務節點/mysql_replicator/tasks/copy_hot_item中去，以便該任務的全部任務機器都可以共享複製任務的配置。

　　在上述熱備份方案中，針對一個任務，都會至少分配兩臺任務機器來進行熱備份（RUNNING和STANDBY、即主備機器），若須要MySQL實例須要進行數據複製，那麼須要消耗太多機器。此時，須要使用冷備份方案，其對全部任務進行分組。

　　Core進程被配置了所屬組（Group），即若一個Core進程被標記了group1，那麼在Core進程啓動後，會到對應的Zookeeper group1節點下面獲取全部的Task列表，假如找到任務"copy_hot_item"以後，就會遍歷這個Task列表的instances節點，但凡尚未子節點，則建立一個臨時的順序節點如/mysql_replicator/task-groups/group1/copy_hot_item/instances/[Hostname]-1，固然，在這個過程當中，其餘Core進程也會在這個instances節點下建立相似的子節點，按照"小序號優先"策略肯定RUNNING，不一樣的是，其餘Core進程會自動刪除本身建立的子節點，而後遍歷下一個Task節點，這樣的過程稱爲冷備份掃描，這樣，全部的Core進程在掃描週期內不斷地對相應的Group下來的Task進行冷備份。

　　在絕大多數分佈式系統中，系統機器間的通訊無外乎心跳檢測、工做進度彙報和系統調度。

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

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

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

　　2.5 集羣管理

　　Zookeeper的兩大特性：

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

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

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

　　分佈式日誌收集系統的核心工做就是收集分佈在不一樣機器上的系統日誌，在典型的日誌系統架構設計中，整個日誌系統會把全部須要收集的日誌機器分爲多個組別，每一個組別對應一個收集器，這個收集器其實就是一個後臺機器，用於收集日誌，對於大規模的分佈式日誌收集系統場景，一般須要解決兩個問題：

　　· 變化的日誌源機器

　　· 變化的收集器機器

　　不管是日誌源機器仍是收集器機器的變動，最終均可以歸結爲如何快速、合理、動態地爲每一個收集器分配對應的日誌源機器。使用Zookeeper的場景步驟以下

　　① 註冊收集器機器，在Zookeeper上建立一個節點做爲收集器的根節點，例如/logs/collector的收集器節點，每一個收集器機器啓動時都會在收集器節點下建立本身的節點，如/logs/collector/[Hostname]

　　② 任務分發，全部收集器機器都建立完對應節點後，系統根據收集器節點下子節點的個數，將全部日誌源機器分紅對應的若干組，而後將分組後的機器列表分別寫到這些收集器機器建立的子節點，如/logs/collector/host1上去。這樣，收集器機器就可以根據本身對應的收集器節點上獲取日誌源機器列表，進而開始進行日誌收集工做。

　　③ 狀態彙報，完成任務分發後，機器隨時會宕機，因此須要有一個收集器的狀態彙報機制，每一個收集器機器上建立完節點後，還須要再對應子節點上建立一個狀態子節點，如/logs/collector/host/status，每一個收集器機器都須要按期向該結點寫入本身的狀態信息，這可看作是心跳檢測機制，一般收集器機器都會寫入日誌收集狀態信息，日誌系統經過判斷狀態子節點最後的更新時間來肯定收集器機器是否存活。

　　④ 動態分配，若收集器機器宕機，則須要動態進行收集任務的分配，收集系統運行過程當中關注/logs/collector節點下全部子節點的變動，一旦有機器中止彙報或有新機器加入，就開始進行任務的從新分配，此時一般由兩種作法：

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

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

　　上述步驟已經完整的說明了整個日誌收集系統的工做流程，其中有兩點注意事項。

　　①節點類型，在/logs/collector節點下建立臨時節點能夠很好的判斷機器是否存活，可是，若機器掛了，其節點會被刪除，記錄在節點上的日誌源機器列表也被清除，因此須要選擇持久節點來標識每一臺機器，同時在節點下分別建立/logs/collector/[Hostname]/status節點來表徵每個收集器機器的狀態，這樣，既能實現對全部機器的監控，同時機器掛掉後，依然可以將分配任務還原。

　　② 日誌系統節點監聽，若採用Watcher機制，那麼通知的消息量的網絡開銷很是大，須要採用日誌系統主動輪詢收集器節點的策略，這樣能夠節省網絡流量，可是存在必定的延時。

　　2.6 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選舉。

　　2.7 分佈式鎖

　　分佈式鎖用於控制分佈式系統之間同步訪問共享資源的一種方式，能夠保證不一樣系統訪問一個或一組資源時的一致性，主要分爲排它鎖和共享鎖。

　　排它鎖又稱爲寫鎖或獨佔鎖，若事務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節點下序號比本身小的那個節點是否存在便可。

　　2.8 分佈式隊列

　　分佈式隊列能夠簡單分爲先入先出隊列模型和等待隊列元素彙集後統一安排處理執行的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。

3、總結

　　本篇博客講解了如何利用Zookeeper的特性來完成典型應用，展現了Zookeeper在解決分佈式問題上的強大做用，基於Zookeeper對分佈式數據一致性的保證及其特性，開發人員可以構建出本身的分佈式系統。也謝謝各位園友的觀看~