zookeeper應用場景

 典型應用場景

　　1.1 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實例須要進行數據複製，那麼須要消耗太多機器。此時，須要使用冷備份方案，其對全部任務進行分組。