共計 4783 個字符，預計需要花費 12 分鐘才能閱讀完成。
本篇文章為大家展示了典型應用場景有哪些，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
ZooKeeper 典型應用場景一覽
ZooKeeper 典型應用場景一覽
數(shù)據(jù)發(fā)布與訂閱（配置中心）發(fā)布與訂閱模型，即所謂的配置中心，顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到 ZK 節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，服務式服務框架的服務地址列表等就非常適合使用。
應用中用到的一些配置信息放到 ZK 上進行集中管理。這類場景通常是這樣：應用在啟動的時候會主動來獲取一次配置，同時，在節(jié)點上注冊一個 Watcher，這樣一來，以后每次配置有更新的時候，都會實時通知到訂閱的客戶端，從來達到獲取最新配置信息的目的。
分布式搜索服務中，索引的元信息和服務器集群機器的節(jié)點狀態(tài)存放在 ZK 的一些指定節(jié)點，供各個客戶端訂閱使用。
分布式日志收集系統(tǒng)。這個系統(tǒng)的核心工作是收集分布在不同機器的日志。收集器通常是按照應用來分配收集任務單元，因此需要在 ZK 上創(chuàng)建一個以應用名作為 path 的節(jié)點 P，并將這個應用的所有機器 ip，以子節(jié)點的形式注冊到節(jié)點 P 上，這樣一來就能夠?qū)崿F(xiàn)機器變動的時候，能夠?qū)崟r通知到收集器調(diào)整任務分配。
系統(tǒng)中有些信息需要動態(tài)獲取，并且還會存在人工手動去修改這個信息的發(fā)問。通常是暴露出接口，例如 JMX 接口，來獲取一些運行時的信息。引入 ZK 之后，就不用自己實現(xiàn)一套方案了，只要將這些信息存放到指定的 ZK 節(jié)點上即可。
注意：在上面提到的應用場景中，有個默認前提是：數(shù)據(jù)量很小，但是數(shù)據(jù)更新可能會比較快的場景。
負載均衡這里說的負載均衡是指軟負載均衡。在分布式環(huán)境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的服務器中選擇一個來執(zhí)行相關(guān)的業(yè)務邏輯，其中比較典型的是消息中間件中的生產(chǎn)者，消費者負載均衡。消息中間件中發(fā)布者和訂閱者的負載均衡，linkedin 開源的 KafkaMQ 和阿里開源的 metaq 都是通過 zookeeper 來做到生產(chǎn)者、消費者的負載均衡。這里以 metaq 為例如講下：
生產(chǎn)者負載均衡：metaq 發(fā)送消息的時候，生產(chǎn)者在發(fā)送消息的時候必須選擇一臺 broker 上的一個分區(qū)來發(fā)送消息，因此 metaq 在運行過程中，會把所有 broker 和對應的分區(qū)信息全部注冊到 ZK 指定節(jié)點上，默認的策略是一個依次輪詢的過程，生產(chǎn)者在通過 ZK 獲取分區(qū)列表之后，會按照 brokerId 和 partition 的順序排列組織成一個有序的分區(qū)列表，發(fā)送的時候按照從頭到尾循環(huán)往復的方式選擇一個分區(qū)來發(fā)送消息。
消費負載均衡：
在消費過程中，一個消費者會消費一個或多個分區(qū)中的消息，但是一個分區(qū)只會由一個消費者來消費。MetaQ 的消費策略是：
每個分區(qū)針對同一個 group 只掛載一個消費者。
如果同一個 group 的消費者數(shù)目大于分區(qū)數(shù)目，則多出來的消費者將不參與消費。
如果同一個 group 的消費者數(shù)目小于分區(qū)數(shù)目，則有部分消費者需要額外承擔消費任務。
在某個消費者故障或者重啟等情況下，其他消費者會感知到這一變化（通過 zookeeper watch 消費者列表），然后重新進行負載均衡，保證所有的分區(qū)都有消費者進行消費。
命名服務 (Naming Service) 命名服務也是分布式系統(tǒng)中比較常見的一類場景。在分布式系統(tǒng)中，通過使用命名服務，客戶端應用能夠根據(jù)指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體通常可以是集群中的機器，提供的服務地址，遠程對象等等——這些我們都可以統(tǒng)稱他們?yōu)槊郑∟ame）。其中較為常見的就是一些分布式服務框架中的服務地址列表。通過調(diào)用 ZK 提供的創(chuàng)建節(jié)點的 API，能夠很容易創(chuàng)建一個全局唯一的 path，這個 path 就可以作為一個名稱。阿里巴巴集團開源的分布式服務框架 Dubbo 中使用 ZooKeeper 來作為其命名服務，維護全局的服務地址列表，點擊這里查看 Dubbo 開源項目。在 Dubbo 實現(xiàn)中：
服務提供者在啟動的時候，向 ZK 上的指定節(jié)點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址，這個操作就完成了服務的發(fā)布。
服務消費者啟動的時候，訂閱 /dubbo/${serviceName}/providers 目錄下的提供者 URL 地址，并向 /dubbo/${serviceName} /consumers 目錄下寫入自己的 URL 地址。
注意，所有向 ZK 上注冊的地址都是臨時節(jié)點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。
另外，Dubbo 還有針對服務粒度的監(jiān)控，方法是訂閱 /dubbo/${serviceName}目錄下所有提供者和消費者的信息。
分布式通知 / 協(xié)調(diào) ZooKeeper 中特有 watcher 注冊與異步通知機制，能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，實現(xiàn)對數(shù)據(jù)變更的實時處理。使用方法通常是不同系統(tǒng)都對 ZK 上同一個 znode 進行注冊，監(jiān)聽 znode 的變化（包括 znode 本身內(nèi)容及子節(jié)點的），其中一個系統(tǒng) update 了 znode，那么另一個系統(tǒng)能夠收到通知，并作出相應處理
另一種心跳檢測機制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來，而是通過 zk 上某個節(jié)點關(guān)聯(lián)，大大減少系統(tǒng)耦合。
另一種系統(tǒng)調(diào)度模式：某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責是控制推送系統(tǒng)進行相應的推送工作。管理人員在控制臺作的一些操作，實際上是修改了 ZK 上某些節(jié)點的狀態(tài)，而 ZK 就把這些變化通知給他們注冊 Watcher 的客戶端，即推送系統(tǒng)，于是，作出相應的推送任務。
另一種工作匯報模式：一些類似于任務分發(fā)系統(tǒng)，子任務啟動后，到 zk 來注冊一個臨時節(jié)點，并且定時將自己的進度進行匯報（將進度寫回這個臨時節(jié)點），這樣任務管理者就能夠?qū)崟r知道任務進度。
總之，使用 zookeeper 來進行分布式通知和協(xié)調(diào)能夠大大降低系統(tǒng)之間的耦合
集群管理與 Master 選舉
集群機器監(jiān)控：這通常用于那種對集群中機器狀態(tài)，機器在線率有較高要求的場景，能夠快速對集群中機器變化作出響應。這樣的場景中，往往有一個監(jiān)控系統(tǒng)，實時檢測集群機器是否存活。過去的做法通常是：監(jiān)控系統(tǒng)通過某種手段（比如 ping）定時檢測每個機器，或者每個機器自己定時向監(jiān)控系統(tǒng)匯報“我還活著”。這種做法可行，但是存在兩個比較明顯的問題：
集群中機器有變動的時候，牽連修改的東西比較多。
有一定的延時。
利用 ZooKeeper 有兩個特性，就可以實時另一種集群機器存活性監(jiān)控系統(tǒng)：
客戶端在節(jié)點 x 上注冊一個 Watcher，那么如果 x? 的子節(jié)點變化了，會通知該客戶端。
創(chuàng)建 EPHEMERAL 類型的節(jié)點，一旦客戶端和服務器的會話結(jié)束或過期，那么該節(jié)點就會消失。
例如，監(jiān)控系統(tǒng)在 /clusterServers 節(jié)點上注冊一個 Watcher，以后每動態(tài)加機器，那么就往 /clusterServers 下創(chuàng)建一個 EPHEMERAL 類型的節(jié)點：/clusterServers/{hostname}. 這樣，監(jiān)控系統(tǒng)就能夠?qū)崟r知道機器的增減情況，至于后續(xù)處理就是監(jiān)控系統(tǒng)的業(yè)務了。
Master 選舉則是 zookeeper 中最為經(jīng)典的應用場景了。
在分布式環(huán)境中，相同的業(yè)務應用分布在不同的機器上，有些業(yè)務邏輯（例如一些耗時的計算，網(wǎng)絡 I / O 處理），往往只需要讓整個集群中的某一臺機器進行執(zhí)行，其余機器可以共享這個結(jié)果，這樣可以大大減少重復勞動，提高性能，于是這個 master 選舉便是這種場景下的碰到的主要問題。
利用 ZooKeeper 的強一致性，能夠保證在分布式高并發(fā)情況下節(jié)點創(chuàng)建的全局唯一性，即：同時有多個客戶端請求創(chuàng)建 /currentMaster 節(jié)點，最終一定只有一個客戶端請求能夠創(chuàng)建成功。利用這個特性，就能很輕易的在分布式環(huán)境中進行集群選取了。
另外，這種場景演化一下，就是動態(tài) Master 選舉。這就要用到?EPHEMERAL_SEQUENTIAL 類型節(jié)點的特性了。
上文中提到，所有客戶端創(chuàng)建請求，最終只有一個能夠創(chuàng)建成功。在這里稍微變化下，就是允許所有請求都能夠創(chuàng)建成功，但是得有個創(chuàng)建順序，于是所有的請求最終在 ZK 上創(chuàng)建結(jié)果的一種可能情況是這樣：/currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個機器作為 Master，如果這個機器掛了，由于他創(chuàng)建的節(jié)點會馬上小時，那么之后最小的那個機器就是 Master 了。
在搜索系統(tǒng)中，如果集群中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引數(shù)據(jù)一致。因此讓集群中的 Master 來進行全量索引的生成，然后同步到集群中其它機器。另外，Master 選舉的容災措施是，可以隨時進行手動指定 master，就是說應用在 zk 在無法獲取 master 信息時，可以通過比如 http 方式，向一個地方獲取 master。
在 Hbase 中，也是使用 ZooKeeper 來實現(xiàn)動態(tài) HMaster 的選舉。在 Hbase 實現(xiàn)中，會在 ZK 上存儲一些 ROOT 表的地址和 HMaster 的地址，HRegionServer 也會把自己以臨時節(jié)點（Ephemeral）的方式注冊到 Zookeeper 中，使得 HMaster 可以隨時感知到各個 HRegionServer 的存活狀態(tài)，同時，一旦 HMaster 出現(xiàn)問題，會重新選舉出一個 HMaster 來運行，從而避免了 HMaster 的單點問題
分布式鎖分布式鎖，這個主要得益于 ZooKeeper 為我們保證了數(shù)據(jù)的強一致性。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。
所謂保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把 zk 上的一個 znode 看作是一把鎖，通過 create znode 的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。
控制時序，就是所有視圖來獲取這個鎖的客戶端，最終都是會被安排執(zhí)行，只是有個全局時序了。做法和上面基本類似，只是這里 /distribute_lock 已經(jīng)預先存在，客戶端在它下面創(chuàng)建臨時有序節(jié)點（這個可以通過節(jié)點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL 來指定）。Zk 的父節(jié)點（/distribute_lock）維持一份 sequence, 保證子節(jié)點創(chuàng)建的時序性，從而也形成了每個客戶端的全局時序。
分布式隊列隊列方面，簡單地講有兩種，一種是常規(guī)的先進先出隊列，另一種是要等到隊列成員聚齊之后的才統(tǒng)一按序執(zhí)行。對于第一種先進先出隊列，和分布式鎖服務中的控制時序場景基本原理一致，這里不再贅述。
第二種隊列其實是在 FIFO 隊列的基礎上作了一個增強。通常可以在 /queue 這個 znode 下預先建立一個 /queue/num 節(jié)點，并且賦值為 n（或者直接給 /queue 賦值 n），表示隊列大小，之后每次有隊列成員加入后，就判斷下是否已經(jīng)到達隊列大小，決定是否可以開始執(zhí)行了。這種用法的典型場景是，分布式環(huán)境中，一個大任務 Task A，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子任務完成（就緒），那么就去 /taskList 下建立自己的臨時時序節(jié)點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發(fā)現(xiàn)自己下面的子節(jié)點滿足指定個數(shù)，就可以進行下一步按序進行處理了。
上述內(nèi)容就是典型應用場景有哪些，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
