




版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
1、Watcher詳解、接口 在 ZooKeeper 中, 接口類 Watcher 用于表示一個標注你的事件處理器,其定義了事件通知相關的邏輯,包含 KeeperState 和 EventType 兩個枚舉類,分別代表了通知狀態(tài)和事件類型,同時定義了事件的回調(diào)方法:process(WatchedEvent event)Watcher 觸發(fā)條件: 增、刪、改 ( 重復修改也會觸發(fā),因為他只告訴你變更了,不告訴你變更多少,需要 C 自己去拿)abstract public void process ( WatchedEvent event
2、 )。 process() 是 Watch 接口中的回調(diào)方法。當 ZooKeeper 向客戶端發(fā)送一個 Watcher 時間通知時,客戶端就會對相應的 process 方法進行回調(diào),從而實現(xiàn)對事件的處理。 like this:syncNodes()方法。 Watcher 設置是開發(fā)中最常見的,需要搞清楚watcher的一些基本特征,對于exists、getdata、getchild對于節(jié)點的不同操作會收到不同的 watcher信息對父節(jié)點的變更以
3、及子節(jié)點的變更都不會觸發(fā)watcher,而對watcher本身節(jié)點以及子節(jié)點的變更會觸發(fā)watcher繼續(xù)。ZooKeeper 使用 WatchedEvent 對象封裝服務端事件并傳遞給 Watcher, 從而方便回調(diào)方法 process 對服務端事件進行處理。WatcherEvent 實體實現(xiàn)了序列化接口,因此可以用于網(wǎng)絡傳輸。數(shù)據(jù)結(jié)構(gòu)如下。Class WatcherEvent type:int state:int path:Stringstate=-112 會話超時狀態(tài)state= -113認證失敗狀態(tài)state=
4、0;1 連接建立中state= 2 (暫時不清楚如何理解這個狀態(tài),ZOO_ASSOCIATING_STATE)state=3 連接已建立狀態(tài)state= 999 無連接狀態(tài)type=1 創(chuàng)建節(jié)點事件type=2 刪除節(jié)點事件type=3 更改節(jié)點事件type=4 子節(jié)點列表變化事件type= -1 會話session事件type=-2 監(jiān)控被移除事件Watcher 發(fā)送過程。 當服務端產(chǎn)生 WatchedEvent 事件之后,會調(diào)用 getWrapper 方法將自己包裝成一個可序列化的 Watcher
5、Event 事件,以便于通過網(wǎng)絡傳輸?shù)娇蛻舳???蛻舳嗽诮邮盏椒斩说倪@個事件對象后,首先會將 WatcherEvent 事件還原成一個 WatchedEvent 事件。并傳遞給 process方法處理。 回調(diào)方法根據(jù)傳入?yún)?shù)解析完整服務端事件。Watcher 發(fā)送的數(shù)據(jù) 無論是 WatcherEvent 還是 WatchedEvent,他對 ZooKeeper 服務端事件的封裝都是極其簡單的。 當 /Test/te
6、st1/1_1節(jié)點發(fā)生變更時,服務端會發(fā)送給客戶端一個“ZNode數(shù)據(jù)變更“ 事件,客戶端也只能接收到如下信息: KeeperState : SyncConnected EventType : NodeDataChanged Path : /zk-b 也就是說,客戶端無法直接從該事件中獲取到對應數(shù)據(jù)節(jié)點的原始數(shù)據(jù)內(nèi)容,以及變更后的新數(shù)據(jù)內(nèi)容。而是客戶端再次主動去重新獲取數(shù)據(jù)。這個也是 ZooKeeper 一個非常重要
7、的特性。Watcher 工作機制服務端發(fā)送不處理邏輯、客戶端發(fā)送并處理邏輯??蛻舳俗?Watcher 創(chuàng)建一個 new ZooKeeper() 客戶端對象實例時,可以傳入一個 Watcher . new ZooKeeper(String connectString,int sessionTimeout, Watcher watcher)
8、 這個Watcher 將作為整個 ZooKeeper 回話期間的默認 Watcher,會一直被保存在客戶端 ZKWatchManager 的 defaultWatcher 中。 另外,ZooKeeper 客戶端也可以通過 getData、 getChildren 和 exist 三個接口來向 ZooKeeper 服務器注冊 Watcher。 列舉個getData 例: public byte getData(String path,
9、boolean watch, Stat stat) public byte getData(final String path,Watcher watch, Stat stat) 第一個通過一個 boolean 參數(shù)來標識是否使用默認 Watcher 進行注冊,具體注冊邏輯與第二個接口一致。注冊 Watcher 后
10、 在 getData 接口注冊 Watcher 后,客戶端首先會對當前客戶端請求 request 進行標記, 將其設置為 ”使用Watcher“監(jiān)聽。同時會封裝一個 Watcher 的注冊信息,WatchRegistration 對象。 用于暫時保存數(shù)據(jù)節(jié)點的路徑 和 Watcher 的對應關系。Packet 與 WatchRegistration。 Packet 類 在 ZooKeeper 中 Packet 可以看做是一個最小的通信協(xié)議單元,用于進行客戶端與服務端之間的網(wǎng)絡傳輸,任何需要傳輸?shù)膶ο蠖夹枰?/p>
11、裝成一個 Packet 對象。 因此,在 ClientCnxn 中 WatchRegistration 又會被封裝到 Packet 中去, 然后放入發(fā)送隊列中等待客戶端發(fā)送。隨后,ZooKeeper 客戶端就會向服務端發(fā)送這個請求,同時等待請求的返回。完成請求發(fā)送后,會由客戶端 SendThread 線程的 readResponse 方法負責接收來自服務端的相應, finishPacket 方法會從 Packet 中取出對象的 Watcher 并注冊到 ZKWatchManager 中去。 WatchRegis
12、tration 封裝到了 Packet 對象中去,但事實上,在底層的網(wǎng)絡傳輸過程中,沒有將 WatchRegistration 對象完全的序列化到底層字節(jié)數(shù)組中去。ZooKeeper 只會將 requestHeader 和 request 兩個屬性進行序列化。 也就是說,即使WatchRegistration 對象唄封裝在了 Packet 中,但是并沒有被序列化到底層字節(jié)數(shù)組中去。因此也就不會進行網(wǎng)絡傳輸了??蛻舳?Watcher 的注冊流程如下: 服務端注冊 Watcher 服務端處理 Watcher 的序列圖:1 Fi
13、nalRequest PcessRequest( ) 中會判斷當前請求是否是需要注冊 Watcher: 1) 如果 ZooKeeper 判斷當前客戶端需要進行 Watcher 注冊,于是就會將當前的 ServerCnxn 對象和數(shù)據(jù)路徑傳入 getData 方法中去。 ServerCnxn 是一個 ZooKeeper 客戶端和服務器之間的連接接口,代表了一個客戶端和服務器的連接。我們可以 ServerCnxn 看做是一個 Watcher 對象。因為他實現(xiàn)了 Watcher 的 proce
14、ss 接口WatcherManager 是 ZooKeeper 服務端 Watcher 的管理者,其內(nèi)部管理的 watchTable 和 watch2Paths 兩個存儲結(jié)構(gòu),分別從兩個維度對 Watcher 進行存儲。 1) watchTable 是從數(shù)據(jù)節(jié)點路徑的粒度管理 Watcher。 2) watch2Paths 是從 Watcher 的粒度來控制事件觸發(fā)的數(shù)據(jù)節(jié)點在服務端,DataTree 中會托管兩個 Watch
15、Manager, 分別是 dataWatches (數(shù)據(jù)變更Watch) 和 childWatches(子節(jié)點變更Watch)。Watcher 觸發(fā)邏輯 1 封裝 WatchedEvent。 將通知狀態(tài) - KeeperState、事件類型 - EventType、節(jié)點路徑 - Path 封裝成一個 WatchedEvent 對象 2 查
16、詢 Watcher。 根據(jù)路徑從 watchTable 中取出對應的 Watcher。若無-沒注冊 直接退出。若有-注冊過 將數(shù)據(jù)提取出來 同時 從wTable w2Paths 中刪除掉。 Watcher 在服務端也是一次性的 3 調(diào)用 process 方法觸發(fā) Watcher ZooK
17、eeper 會把當前請求對應的 ServerCnxn 作為一個 Watcher 存儲,因此調(diào)用 process 方法,事實上就是 ServerCnxn 對應的 process 方法。客戶端回調(diào) Watcher 1 反序列化 字節(jié)流轉(zhuǎn)換成 WatcherEvent 對象 2 處理 chrootPath
18、0; 如果客戶端設置了 chrootPath 屬性,那么需要對服務器傳過來的完整節(jié)點路徑進行 chrootPath 處理,生成客戶端的一個相對節(jié)點路徑。 例如客戶端 cPath路徑 /Test/test1 那么針對服務端傳過來的相應包含的節(jié)點路徑為/Test/test1/1_19, 經(jīng)過chrootPath 處理后 會變成一個相對路徑:/ 1_19. 3 還原 WatchedEvent
19、0; WatcherEvent 轉(zhuǎn)換成 WatchedEvent. 4 回調(diào) Watcher。 最后將 WatcherEvent 對象交給 EventThread 線程,在下一個輪詢周期中進行 Watcher 回調(diào)。EventThread 處理時間通知。&
20、#160; SendThread 接收到服務端的通知事件后,會通過調(diào)用 EventThread.queueEvent 方法將事件傳給 EventThread 線程。queueEvent 方法首先會根據(jù)該通知事件,從 ZKWatchManager 中取出所有相關的 Watcher 客戶端識別出 事件類型 EventType 后,會從相應的 Watcher 存儲 (即3個注冊方法)中去除對應的 Watcher。獲取到相關的所有 Watcher 后,會將其放入 waitingEvents 這個隊列去。
21、 注意 此處調(diào)用的是 remove 接口。 客戶端的 Watcher 同樣也是一次性的。即一旦被觸發(fā),該Watcher 就失效了。 3個注冊方法: dataWatches、existWatcher 或 childWatcher 中的一個或多個 waitingEvents 是一個待處理 Watcher 的隊列,EventThread 的 run 方法會不斷對該隊列進行處理Watcher 特性總結(jié): 一次性 &
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 酒店產(chǎn)權歸屬協(xié)議書
- 茶地種植合同協(xié)議書
- 配合申報工傷協(xié)議書
- 人工費調(diào)整補充協(xié)議書
- 辦公室家具供貨協(xié)議書
- 鄰居舊房拆建協(xié)議書
- 集體商鋪轉(zhuǎn)讓協(xié)議書
- 進京車輛租賃協(xié)議書
- 菜鳥驛站合伙協(xié)議書
- 餐飲海鮮合作協(xié)議書
- 信息技術服務質(zhì)量承諾及保障措施
- GB 19646-2025食品安全國家標準稀奶油、奶油和無水奶油
- 電力交易員試題及答案
- 宗地圖測繪合同協(xié)議
- 網(wǎng)約車租賃合同協(xié)議書
- 物業(yè)話術培訓
- 2025年檸條項目可行性研究報告
- 女生日常行為規(guī)范
- 寫字樓保安知識培訓課件
- 水果店創(chuàng)業(yè)藍圖:市場分析與經(jīng)營策略
- 2025-2030中國鼻腔護理液行業(yè)市場現(xiàn)狀分析及競爭格局與投資發(fā)展研究報告
評論
0/150
提交評論