1. 程式人生 > >說說zookeeper【肆】_應用場景

說說zookeeper【肆】_應用場景

在系列第一篇文章中,我們已經整理了zookeeper在分散式應用中的使用場景:

可基於zookeeper實現資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、master選舉、分散式鎖和分散式佇列等功能。

下面我們依次詳細介紹一下具體實現。

資料釋出/訂閱 即所謂配置中心,就是釋出者將資料釋出到zookeeper的一個或一系列節點上,供訂閱者進行資料訂閱,達到獲取資料的目的,實現配置資訊的集中式管理和資料的動態更新。 通常有兩種實現模式:推模式模式 推模式是服務端主動將資料更新發送給素有訂閱的客戶端,拉模式是客戶單主動發起請求來獲取最新資料,通常採用定時輪詢拉取的方式。
zookeeper採用推拉相結合方式:客戶端向伺服器註冊關注的節點,一旦該節點資料變更,那麼服務端就會向客戶端傳送watcher時間通知,客戶端收到通知後,主動到服務端獲取最新的資料。 負載均衡 動態DNS,在zookeeper上建立一個節點進行域名配置,每個應用可以將自己的域名配置上去,並建立一個屬於自己的資料節點作為域名配置的根節點。 命名服務 在分散式系統中,被命名的實體通常可以是叢集中的機器、提供的服務地址或遠端物件等,較為常見的就是一些分散式服務框架(RPC、RMI)中的服務地址列表。通過使用命名服務,客戶端應用能夠根據指定名字來獲取資源的實體、服務地址和提供者的資訊等。
zookeeper通過API介面可建立順序節點,並且在API返回值中會返回這個節點的完整名字。利用這個特性,我們可以藉助zookeeper生成全域性唯一ID。 分散式協調/通知 zookeeper中特有的watcher註冊與非同步通知機制,能夠很好地實現分散式環境下不同機器,甚至是不同系統之間的協調與通知,從而實現對資料變更的實時處理。基於zookeeper實現分散式協調與通知功能,通常的做法是不同的客戶端都對zookeeper上同一個資料節點進行watcher註冊,監聽資料節點的變化(包括資料節點本身及其子節點),如果資料節點發生變化,那麼所有訂閱的客戶端都能夠接收到響應的watcher通知,並作出相應的處理。
具體功能實現包括心跳檢測、工作進度彙報、系統排程等。 叢集管理 包括叢集監控和叢集控制兩大塊,前者側重對叢集執行時狀態的收集,後者則是對叢集進行操作與控制。可以利用zookeeper一下兩大特性實現: 1.客戶端如果對zookeeper的一個數據節點註冊watcher監聽,那麼當資料節點的內容或其子節點列表發生變更時,zookeeper伺服器就會向訂閱的客戶端傳送變更通知; 2.對在zookeeper上建立的臨時節點,一旦客戶端與伺服器之間的會話失效,那麼該臨時節點也就被自動清除。 分散式日誌收集 使用zookeeper來進行日誌系統收集器的註冊,典型做法是在zookeeper上建立一個節點作為收集器的根節點(如logs/collector),每個收集器機器在啟動時,都會在收集器節點下建立自己的節點(logs/collector/machine1永久節點)。同時在節點下維護一個狀態節點(logs/collector/machine1/status),用於記錄狀態。 master選舉 客戶端叢集每天定時向zookeeper上建立一個臨時節點,在此過程中只有一個客戶端能夠成功建立,那麼這個客戶端就是master。同時其他客戶端則註冊一個watcher在這個節點上,用於監控當前master機器是否存活,以便 重新發起master選舉。 分散式鎖 分散式鎖是控制分散式系統之間同步訪問共享資源的一種方式,分為互斥鎖和共享鎖兩種實現形式。 互斥鎖 通過互斥保證一致性。實現方式是客戶端叢集向zookeeper上建立一個臨時節點,在此過程中只有一個客戶端能夠成功建立,當客戶端處理完邏輯或宕機時,zookeeper會自動刪除這個節點,其他客戶端可繼續競爭建立此節點。 共享鎖 一般場景為讀寫鎖的讀寫操作分離。實現方式是客戶端建立一個節點,類似"hostname-請求型別-序號",然後獲取所有已經建立的節點。 讀鎖:如果比自己序號小的節點都是讀操作,則直接執行;如果不是,則在比自己小的最後一個寫請求節點加上watcher事件; 寫鎖:如果自己不是最小序號節點,就在自己小的最後一個節點加上watcher事件; 分散式佇列 FIFO 參照分散式鎖-共享鎖的寫鎖實現。 Barrier 在一個節點設定屏障大小,註冊watcher事件在節點上,關注節點下子節點數,如果達到屏障大小則觸發。