溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關(guān)zookeeper有哪些常用的使用場景，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
ZooKeeper是一個高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架?；趯axos算法的實現(xiàn)，使該框架保證了分布式環(huán)境中數(shù)據(jù)的強一致性，也正是基于這樣的特性，使得zookeeper能夠應(yīng)用于很多場景。網(wǎng)上對zk的使用場景也有不少介紹，本文將結(jié)合作者身邊的項目例子，系統(tǒng)的對zk的使用場景進行歸類介紹。 值得注意的是，zk并不是生來就為這些場景設(shè)計，都是后來眾多開發(fā)者根據(jù)框架的特性，摸索出來的典型使用方法。因此，也非常歡迎你分享你在ZK使用上的奇技淫巧。
| 場景類別 | 典型場景描述（ZK特性，使用方法） | 應(yīng)用中的具體使用 |
| 數(shù)據(jù)發(fā)布與訂閱 | 發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數(shù)據(jù)發(fā)布到zk節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，地址列表等就非常適合使用。 | 1. 索引信息和集群中機器節(jié)點狀態(tài)存放在zk的一些指定節(jié)點，供各個客戶端訂閱使用。2. 系統(tǒng)日志（經(jīng)過處理后的）存儲，這些日志通常2-3天后被清除。 3. 應(yīng)用中用到的一些配置信息集中管理，在應(yīng)用啟動的時候主動來獲取一次，并且在節(jié)點上注冊一個Watcher，以后每次配置有更新，實時通知到應(yīng)用，獲取最新配置信息。 4. 業(yè)務(wù)邏輯中需要用到的一些全局變量，比如一些消息中間件的消息隊列通常有個offset，這個offset存放在zk上，這樣集群中每個發(fā)送者都能知道當前的發(fā)送進度。 5. 系統(tǒng)中有些信息需要動態(tài)獲取，并且還會存在人工手動去修改這個信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要將這些信息存放到zk節(jié)點上即可。 |
| Name Service | 這個主要是作為分布式命名服務(wù)，通過調(diào)用zk的create node api，能夠很容易創(chuàng)建一個全局唯一的path，這個path就可以作為一個名稱。 | |
| 分布通知/協(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)能夠收到通知，并作出相應(yīng)處理。 | 1. 另一種心跳檢測機制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來，而是通過zk上某個節(jié)點關(guān)聯(lián)，大大減少系統(tǒng)耦合。2. 另一種系統(tǒng)調(diào)度模式：某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責(zé)是控制推送系統(tǒng)進行相應(yīng)的推送工作。管理人員在控制臺作的一些操作，實際上是修改了ZK上某些節(jié)點的狀態(tài)，而zk就把這些變化通知給他們注冊Watcher的客戶端，即推送系統(tǒng)，于是，作出相應(yīng)的推送任務(wù)。 3. 另一種工作匯報模式：一些類似于任務(wù)分發(fā)系統(tǒng)，子任務(wù)啟動后，到zk來注冊一個臨時節(jié)點，并且定時將自己的進度進行匯報（將進度寫回這個臨時節(jié)點），這樣任務(wù)管理者就能夠?qū)崟r知道任務(wù)進度。 總之，使用zookeeper來進行分布式通知和協(xié)調(diào)能夠大大降低系統(tǒng)之間的耦合。 |
| 分布式鎖 | 分布式鎖，這個主要得益于ZooKeeper為我們保證了數(shù)據(jù)的強一致性，即用戶只要完全相信每時每刻，zk集群中任意節(jié)點（一個zk server）上的相同znode的數(shù)據(jù)是一定是相同的。鎖服務(wù)可以分為兩類，一個是保持獨占，另一個是控制時序。 所謂保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。 控制時序，就是所有視圖來獲取這個鎖的客戶端，最終都是會被安排執(zhí)行，只是有個全局時序了。做法和上面基本類似，只是這里 /distribute_lock 已經(jīng)預(yù)先存在，客戶端在它下面創(chuàng)建臨時有序節(jié)點（這個可以通過節(jié)點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節(jié)點（/distribute_lock）維持一份sequence,保證子節(jié)點創(chuàng)建的時序性，從而也形成了每個客戶端的全局時序。 | |
| 集群管理 | 1. 集群機器監(jiān)控：這通常用于那種對集群中機器狀態(tài)，機器在線率有較高要求的場景，能夠快速對集群中機器變化作出響應(yīng)。這樣的場景中，往往有一個監(jiān)控系統(tǒng)，實時檢測集群機器是否存活。過去的做法通常是：監(jiān)控系統(tǒng)通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監(jiān)控系統(tǒng)匯報“我還活著”。 這種做法可行，但是存在兩個比較明顯的問題：1. 集群中機器有變動的時候，牽連修改的東西比較多。2. 有一定的延時。 利用ZooKeeper有兩個特性，就可以實時另一種集群機器存活性監(jiān)控系統(tǒng)：a. 客戶端在節(jié)點 x 上注冊一個Watcher，那么如果 x 的子節(jié)點變化了，會通知該客戶端。b. 創(chuàng)建EPHEMERAL類型的節(jié)點，一旦客戶端和服務(wù)器的會話結(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è)務(wù)了。 在分布式環(huán)境中，相同的業(yè)務(wù)應(yīng)用分布在不同的機器上，有些業(yè)務(wù)邏輯（例如一些耗時的計算，網(wǎng)絡(luò)I/O處理），往往只需要讓整個集群中的某一臺機器進行執(zhí)行，其余機器可以共享這個結(jié)果，這樣可以大大減少重復(fù)勞動，提高性能，于是這個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了。 | 1. 在搜索系統(tǒng)中，如果集群中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引數(shù)據(jù)一致。因此讓集群中的Master來進行全量索引的生成，然后同步到集群中其它機器。2. 另外，Master選舉的容災(zāi)措施是，可以隨時進行手動指定master，就是說應(yīng)用在zk在無法獲取master信息時，可以通過比如http方式，向一個地方獲取master。 |
| 分布式隊列 | 隊列方面，我目前感覺有兩種，一種是常規(guī)的先進先出隊列，另一種是要等到隊列成員聚齊之后的才統(tǒng)一按序執(zhí)行。對于第二種先進先出隊列，和分布式鎖服務(wù)中的控制時序場景基本原理一致，這里不再贅述。 第二種隊列其實是在FIFO隊列的基礎(chǔ)上作了一個增強。通?？梢栽?/queue 這個znode下預(yù)先建立一個/queue/num 節(jié)點，并且賦值為n（或者直接給/queue賦值n），表示隊列大小，之后每次有隊列成員加入后，就判斷下是否已經(jīng)到達隊列大小，決定是否可以開始執(zhí)行了。這種用法的典型場景是，分布式環(huán)境中，一個大任務(wù)Task A，需要在很多子任務(wù)完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子任務(wù)完成（就緒），那么就去 /taskList 下建立自己的臨時時序節(jié)點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發(fā)現(xiàn)自己下面的子節(jié)點滿足指定個數(shù)，就可以進行下一步按序進行處理了。 |
看完上述內(nèi)容，你們對zookeeper有哪些常用的使用場景有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼
