一惭每、Zookeeper簡介
1.1. Zookeeper 簡介
??Zookeeper是一套分布式鎖管理系統(tǒng)，運用到了paxos 算法解決的一個分布式事務管理的系統(tǒng)，主要是用來解決分布式應用中經(jīng)常遇到的一些數(shù)據(jù)管理問題婚惫，可以高可靠的維護元數(shù)據(jù)椿胯。提供的功能包括：配置維護筷登、名字服務、分布式同步哩盲、組服務等前方。ZooKeeper的設計目標就是封裝好復雜易出錯的關鍵服務狈醉，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶惠险。
??Zookeeper 作為一個分布式的服務框架苗傅，主要用來解決分布式集群中應用系統(tǒng)的一致性問題，它能提供基于類似于文件系統(tǒng)的目錄節(jié)點樹方式的數(shù)據(jù)存儲班巩。需要注意渣慕，zookeeper并不是用來專門存儲數(shù)據(jù)的，它主要用來維護和監(jiān)控系統(tǒng)存儲的數(shù)據(jù)的狀態(tài)的變化的抱慌。通過監(jiān)控這些數(shù)據(jù)狀態(tài)的變化逊桦，從而可以達到基于數(shù)據(jù)的集群管理。ZooKeeper所提供的服務主要是通過：數(shù)據(jù)結構+原語+watcher機制,三個部分來實現(xiàn)的抑进。
1.2 "數(shù)據(jù)"是有限制的：
(1) 從數(shù)據(jù)大小來看：
ZooKeeper的數(shù)據(jù)存儲在一個叫ReplicatedDataBase 的 數(shù)據(jù)庫中强经，該數(shù)據(jù)是一個內(nèi)存數(shù)據(jù)庫，既然是在內(nèi)存當中单匣，
數(shù)據(jù)量不會很大夕凝，這與HDFS的數(shù)據(jù)存儲在磁盤上。
(2) 從數(shù)據(jù)類型來看：
Zookeeper的數(shù)據(jù)存儲在內(nèi)存中户秤，由于內(nèi)存空間的限制码秉，那么久不能再上面存儲過多數(shù)據(jù)故，存儲的數(shù)據(jù)需要根據(jù)需求和功能
進行選擇鸡号，都是由ZK節(jié)點的性質(zhì)和該節(jié)點所關聯(lián)的數(shù)據(jù)實現(xiàn)的转砖。
例如：
① 集群管理：利用臨時節(jié)點特性鲸伴，節(jié)點關聯(lián)的是機器的主機名府蔗，ip地址等相關信息，集群單點故障也屬于這個范疇汞窗。
⌒粘唷② 統(tǒng)一命名：主要利用節(jié)點的唯一性和目錄節(jié)點樹結構。仲吏、
〔幻③ 配置管理：節(jié)點關聯(lián)的是配置信息。
」簟④ 分布式鎖：節(jié)點關聯(lián)的是要競爭的資源誓斥。
1.3 數(shù)據(jù)訪問
??ZooKeeper中的每個節(jié)點存儲的數(shù)據(jù)要被原子性的操作。也就是說讀操作將獲取與節(jié)點相關的所有數(shù)據(jù)许帐，寫操作也將替換掉節(jié)點的所有數(shù)據(jù)劳坑。另外，每一個節(jié)點都擁有自己的ACL(訪問控制列表)成畦，這個列表規(guī)定了用戶的權限距芬，即限定了特定用戶對目標節(jié)點可以執(zhí)行的操作涝开。
1.4 節(jié)點類型
??ZooKeeper中的節(jié)點有兩種，分別為臨時節(jié)點和永久節(jié)點蔑穴。節(jié)點的類型在創(chuàng)建時即被確定忠寻，并且不能改變。
① 臨時節(jié)點：該節(jié)點的生命周期依賴于創(chuàng)建它們的會話存和。一旦會話(Session)結束奕剃，臨時節(jié)點將被自動刪除，當然可以也可以手動刪除捐腿。雖然每個臨時的Znode都會綁定到一個客戶端會話纵朋，但他們對所有的客戶端還是可見的。另外茄袖，ZooKeeper的臨時節(jié)點不允許擁有子節(jié)點操软。
② 永久節(jié)點：該節(jié)點的生命周期不依賴于會話，并且只有在客戶端顯示執(zhí)行刪除操作的時候宪祥，他們才能被刪除聂薪。
1.5 引用方式
Zonde通過路徑引用，如同Unix中的文件路徑蝗羊。路徑必須是絕對的藏澳，因此他們必須由斜杠字符來開頭。除此以外耀找，他們必須是唯一的翔悠，也就是說每一個路徑只有一個表示，因此這些路徑不能改變野芒。在ZooKeeper中蓄愁，路徑由Unicode字符串組成，并且有一些限制狞悲。字符串"/zookeeper"用以保存管理信息撮抓，比如關鍵配額信息。
二摇锋、ZooKeeper應用場景
??ZooKeeper是一個高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架丹拯。是基于Paxos算法實現(xiàn)的，使得該框架能夠保證分部署環(huán)境中數(shù)據(jù)的強一致性乱投，基于此特性，使得zookeeper能夠引用于很多場景顷编，任何功能的實現(xiàn)都是利用"Znode結構特性+節(jié)點關聯(lián)的數(shù)據(jù)"來實現(xiàn)的
Zookeeper數(shù)據(jù)結構 戚炫，如下圖：
Zookeeper 這種數(shù)據(jù)結構有如下這些特點：
① 每個子目錄項如NameService都被稱作znode，這個znode是被它所在的路徑的唯一標識媳纬，
如双肤，Server1這個znode的標識為/NameService/Server1
② znode可以有子節(jié)點目錄施掏，并且每個znode都可以存儲數(shù)據(jù)，注意：EPHEMERAL類型的目錄節(jié)點不能有子節(jié)點目錄茅糜；
③ znode 是有版本的七芭，每個znode中存儲的數(shù)據(jù)可以有多個版本，也就是一個訪問路徑中可以存儲多份數(shù)據(jù)蔑赘；
④ znode 可以是臨時節(jié)點狸驳，一旦創(chuàng)建了這個znode的客戶端與服務器失去聯(lián)系，這個znode也將自動刪除缩赛，Zookeeper的客戶端和
服務器端通信采用長連接耙箍，每個客戶端和服務器通過心跳來保持連接，這個連接狀態(tài)成為session酥馍，如果znode是臨時節(jié)點辩昆，
這個session失效，znode也就刪除了旨袒。
⑤ znode 的目錄名可以自動編號汁针，如 App1 已經(jīng)存在，再創(chuàng)建的話砚尽，將會自動命名為 App2施无；
⑥ znode 可以被監(jiān)控，包括這個目錄節(jié)點中存儲的數(shù)據(jù)的修改尉辑，子節(jié)點目錄的變化等帆精，一旦變化可以通知設置監(jiān)控的客戶端，
這個是 Zookeeper 的核心特性隧魄，Zookeeper 的很多功能都是基于這個特性實現(xiàn)的卓练。
??ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特點购啄。既像文件一樣維護著數(shù)據(jù)襟企、元信息、ACL狮含、時間戳等數(shù)據(jù)結構顽悼，又像目錄一樣可以作為路徑標識的一部分。圖中的每個節(jié)點稱為一個Znode几迄。ZooKeeper雖然可以關聯(lián)一些數(shù)據(jù)蔚龙，但并沒有被設計為常規(guī)的數(shù)據(jù)庫或者大數(shù)據(jù)存儲，相反的是映胁，它用來管理調(diào)度數(shù)據(jù)木羹，比如分布式應用中的配置文件信息、狀態(tài)信息、匯集位置等等坑填。這些數(shù)據(jù)的共同特性就是它們都是很小的數(shù)據(jù)抛人，通常以KB為大小單位。ZooKeeper的服務器和客戶端都被設計為嚴格檢查并限制每個Znode的數(shù)據(jù)大小至多1M脐瑰，但常規(guī)使用中應該遠小于此值妖枚。
Znode由3部分組成:
① stat：此為狀態(tài)信息, 描述該Znode的版本, 權限等信息
② data：與該Znode關聯(lián)的數(shù)據(jù)
③ children：該Znode下的子節(jié)點
2.1數(shù)據(jù)發(fā)布與訂閱（即配置管理）
(1) 典型場景描述
??發(fā)布與訂閱，即所謂的配置管理苍在，就是將數(shù)據(jù)發(fā)布到zk節(jié)點上绝页，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中管理和動態(tài)更新忌穿。例如：全局的配置信息抒寂，地址列表等就非常適合使用。 集中式的配置管理在應用集群中是非常常見的掠剑，一般商業(yè)公司內(nèi)部都會實現(xiàn)一套集中的配置管理中心屈芜，應對不同的應用集群對于共享各自配置的需求，并且在配置變更時能夠通知到集群中的每個機器朴译。
(2) 應用
① 索引信息和集群中機器節(jié)點狀態(tài)存放在zk的一些指定節(jié)點井佑，供各個客戶端訂閱使用。
② 系統(tǒng)日志（經(jīng)過處理后）的存儲日志眠寿，通常為2-3天躬翁，然后會被清理。
③ 應用中用到的一些配置信息集中管理盯拱，在應用啟動的時候主動來獲取一次盒发，并且在節(jié)點上注冊一個watcher，以后每次配置有更新狡逢，
實時通知應用宁舰，獲取最新配置信息。
④ 業(yè)務邏輯中需要用到一些全局變量奢浑，比如一些消息中間件的消息隊列通常有個offset蛮艰，此時這個offset存放在zk上，這樣集群每次
發(fā)送者都能知道當前的發(fā)送進度雀彼。
⑤ 系統(tǒng)中有些信息需要動態(tài)獲取壤蚜，并且還會存在人工手動去修改這個信息。以前通常是暴露出接口徊哑，例如JMX接口袜刷，有了ZK后，只要將這
些信息存放到ZK節(jié)點上即可
(3) 應用舉例
??例如：同一個應用系統(tǒng)需要多臺PC Server運行莺丑，但是他們運行的應用系統(tǒng)的某些配置項是相同的著蟹，如果要修改這些相同的配置項，那么久必須同時修改每臺運行這個應用系統(tǒng)的PC Server，這樣非常麻煩草则，而且容易出錯。將配置信息保存在zookeeper的某個節(jié)點中蟹漓，然后將所有需要修改的應用機器監(jiān)控配置信息的狀態(tài)炕横，一旦配置信息發(fā)生變化，每臺應用機器就會收到zookeeper的通知葡粒，然后從zookeeper獲取新的配置信息應用到系統(tǒng)中份殿。ZooKeeper配置管理服務如下圖所示：
??Zookeeper非常容易實現(xiàn)這種集中式的配置管理，比如嗽交，將所需要的配置信息放到
/Configurtaion節(jié)點上卿嘲，集群中所有機器一啟動就會通過Client對/Configuration 這個節(jié)點進行監(jiān)控zk.exist("/Configuration″,true),并且實現(xiàn)Watcher回調(diào)方法 process(),那么在zookeeper上/Configurtaion節(jié)點下數(shù)據(jù)發(fā)生變化的時候，每個機器都會收到通知夫壁，Watcher回調(diào)方法將會被執(zhí)行拾枣，那么應用再去下數(shù)據(jù)即可zk.getData("/Configuration″,false,null)。
2.2統(tǒng)一命名服務（Name Service）
(1) 典型場景描述
??分布式應用中盒让，通常需要有一套完整的命名規(guī)則梅肤，能夠產(chǎn)生唯一的名稱，通常情況先邑茄，用樹形的名稱結構是一個理想的選擇姨蝴，樹形的名稱結構是一個有層次的目錄結構，即對人友好又不會重復肺缕。將有層次的目錄結構關聯(lián)到一定資源上左医。
(2) 應用
??在分布式系統(tǒng)中個，通過使用命名服務同木，客戶端應該能夠根據(jù)指定的名字來獲取資源服務的地址浮梢、提供者等信息。被命名的實體通橙郑可以是集群中的機器黔寇，提供服務地址、進程對象等斩萌，這些統(tǒng)稱為名字（Name）缝裤。其中較為常見的是一些分布式服務框架中的服務地址列表。通過調(diào)用ZK提供的創(chuàng)建節(jié)點的API颊郎，能夠很容易創(chuàng)建一個全局唯一的path憋飞，這個path就可以作為一個名稱Name。Name Service已經(jīng)是Zookeeper內(nèi)置的功能姆吭。你只要調(diào)用zookeeper的api就能實現(xiàn)榛做。
(3) 應用舉例
??分布式服務框架Dubbo中使用zookeeper來作為其命名服務，維護全局的服務地址列表。在Dubbo是實現(xiàn)中：服務提供者provider在啟動的時候检眯，向Zookeeper的指定節(jié)點:~/dubbo/${serviceName}/providers目錄下寫入自己的URL地址厘擂，這個操作就會完成服務的發(fā)布。一般數(shù)據(jù)存放路徑為 /zookeeper-xxx/data/version-xx/log.x锰瘸。
??服務消費者啟動的時候刽严，訂閱~/dubbo/${serviceName}/providers目錄下的提供者URL地址。注意：所有向ZK上注冊的地址都是臨時節(jié)點避凝，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化舞萄。Dubbo還有針對服務粒度的監(jiān)控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的信息管削。
2.3分布通知/協(xié)調(diào)（Distribution of notification/coordination）
(1) 典型場景描述
??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)能夠收到通知吊履，并作出相應處理。
(2) 應用
① 一種心跳檢測機制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關聯(lián)起來调鬓，而是通過ZK上某個節(jié)點關聯(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é)點）吴旋，這樣任務管理者就能夠實時知道任務進度受啥。
總之，使用zookeeper來進行分布式通知和協(xié)調(diào)能夠大大降低系統(tǒng)之間的耦合。
2.4分布式鎖（Distribute Lock）
(1) 典型場景描述
??分布式鎖捏检，主要得益于Zookeeper能夠保證數(shù)據(jù)的強一致性梁丘，用戶只要完全相應每時每刻择浊，zk集群中任意節(jié)點（一個zk server）上的相同znode的數(shù)據(jù)時一定是相同的追城。
鎖服務可以分為兩類范咨，一個是保持獨占，另一個是控制時序厂庇。
- 保持獨占:
??就是所有試圖來獲取這個鎖的客戶端渠啊，最終只有一個可以成功獲得這把鎖。通常的做法是把ZK上的一個znode看作是一把鎖权旷，通過create znode的方式來實現(xiàn)昭抒。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖炼杖。 - 控制時序:
??就是所有試圖來獲取這個鎖的客戶端，最終都是會被安排執(zhí)行盗迟，只是有 個全局時序了坤邪。做法和上面基本類似，只是這里 /distribute_lock 已經(jīng)預先存在罚缕，客戶端在它下面創(chuàng)建臨時有序節(jié)點艇纺。Zk的父節(jié)點（/distribute_lock）維持一份sequence,保證子節(jié)點創(chuàng)建的時序性， 從而也形成了每個客戶端的全局時序邮弹。
(2) 應用
??共享鎖在同一個進程中很容易實現(xiàn)黔衡，但是在跨進程或者在不同 Server 之間就不好實現(xiàn)了。Zookeeper 卻很容易實現(xiàn)這個功能腌乡，實現(xiàn)方式也是需要獲得鎖的 Server 創(chuàng)建一個 EPHEMERAL_SEQUENTIAL 目錄節(jié)點盟劫，然后調(diào)用 getChildren方法獲取當前的目錄節(jié)點列表中最小的目錄節(jié)點是不是就是自己創(chuàng)建的目錄節(jié)點，如果正是自己創(chuàng)建的与纽，那么它就獲得了這個鎖侣签，如果不是那么它就調(diào)用 exists(String path, boolean watch)方法并監(jiān)控 Zookeeper 上目錄節(jié)點列表的變化，一直到自己創(chuàng)建的節(jié)點是列表中最小編號的目錄節(jié)點急迂，從而獲得鎖影所，釋放鎖很簡單，只要刪除前面它自己所創(chuàng)建的目錄節(jié)點就行了僚碎。
其中節(jié)點被組織成目錄樹的形式猴娩，每個節(jié)點下面都可以有一些子節(jié)點。節(jié)點可以是以下四種類型：
PERSISTENT：持久化目錄節(jié)點勺阐，這個目錄節(jié)點存儲的數(shù)據(jù)不會丟失卷中；
PERSISTENT_SEQUENTIAL：順序自動編號的目錄節(jié)點，這種目錄節(jié)點會根據(jù)當前已近存在的節(jié)點數(shù)自動加 1渊抽，然后返回給客戶端已經(jīng)成功創(chuàng)建的目錄節(jié)點名仓坞；
EPHEMERAL：臨時目錄節(jié)點，一旦創(chuàng)建這個節(jié)點的客戶端與服務器端口也就是 session 超時腰吟，這種節(jié)點會被自動刪除无埃；
EPHEMERAL_SEQUENTIAL：臨時自動編號節(jié)點徙瓶。監(jiān)控節(jié)點變化時，可以監(jiān)控一個節(jié)點的變化嫉称，也可以監(jiān)控一個節(jié)點所有子節(jié)點的變化侦镇。
(2) 詳細描述
??在分布式鎖服務中，有一種最典型應用場景织阅，就是通過對集群進行Master選舉壳繁，來解決分布式系統(tǒng)中的單點故障。什么是分布式系統(tǒng)中的單點故障：通常分布式系統(tǒng)采用主從模式荔棉，就是一個主控機連接多個處理節(jié)點闹炉。主節(jié)點負責分發(fā)任務，從節(jié)點負責處理任務润樱，當我們的主節(jié)點發(fā)生故障時渣触，那么整個系統(tǒng)就都癱瘓了，那么我們把這種故障叫作單點故障壹若。
-
傳統(tǒng)解決方案
?? 傳統(tǒng)方式是采用一個備用節(jié)點嗅钻，這個備用節(jié)點定期給當前主節(jié)點發(fā)送ping包，主節(jié)點收到ping包以后向備用節(jié)點發(fā)送回復Ack店展，當備用節(jié)點收到回復的時候就會認為當前主節(jié)點還活著养篓，讓他繼續(xù)提供服務。
當主節(jié)點掛了赂蕴，這時候備用節(jié)點收不到回復了柳弄，然后他就認為主節(jié)點掛了接替他成為主節(jié)點
但是這種方式就是有一個
隱患，就是網(wǎng)絡問題概说，來看一網(wǎng)絡問題會造成什么后果
也就是說我們的主節(jié)點的并沒有掛语御，只是在回復的時候網(wǎng)絡發(fā)生故障，這樣我們的備用節(jié)點同樣收不到回復席怪，就會認為主節(jié)點掛了应闯，然后備用節(jié)點將他的Master實例啟動起來，這樣我們的分布式系統(tǒng)當中就有了兩個主節(jié)點也就是---
雙Master挂捻，出現(xiàn)Master以后我們的從節(jié)點就會將它所做的事一部分匯報給了主節(jié)點碉纺，一部分匯報給了從節(jié)點，這樣服務就全亂了刻撒。為了防止出現(xiàn)這種情況骨田，我們引入了ZooKeeper，它雖然不能避免網(wǎng)絡故障声怔，但它能夠保證每時每刻只有一個Master态贤。我么來看一下ZooKeeper是如何實現(xiàn)的。
-
ZooKeeper解決方案
(1) Master啟動
?? 在引入了Zookeeper以后我們啟動了兩個主節(jié)點醋火，"主節(jié)點-A"和"主節(jié)點-B"他們啟動以后悠汽，都向ZooKeeper去注冊一個節(jié)點箱吕。我們假設"主節(jié)點-A"鎖注冊地節(jié)點是"master-00001"，"主節(jié)點-B"注冊的節(jié)點是"master-00002"柿冲，注冊完以后進行選舉茬高，編號最小的節(jié)點將在選舉中獲勝獲得鎖成為主節(jié)點，也就是我們的"主節(jié)點-A"將會獲得鎖成為主節(jié)點假抄，然后"主節(jié)點-B"將被阻塞成為一個備用節(jié)點怎栽。那么，通過這種方式就完成了對兩個Master進程的調(diào)度宿饱。
(2) Master故障
如果"主節(jié)點-A"掛了熏瞄，這時候他所注冊的節(jié)點將被自動刪除，ZooKeeper會自動感知節(jié)點的變化谬以，然后再次發(fā)出選舉强饮，這時候"主節(jié)點-B"將在選舉中獲勝，替代"主節(jié)點-A"成為主節(jié)點蛉签。
(3) Master 恢復
如果主節(jié)點恢復了，他會再次向ZooKeeper注冊一個節(jié)點沥寥，這時候他注冊的節(jié)點將會是"master-00003"碍舍，ZooKeeper會感知節(jié)點的變化再次發(fā)動選舉，這時候"主節(jié)點-B"在選舉中會再次獲勝繼續(xù)擔任"主節(jié)點"邑雅，"主節(jié)點-A"會擔任備用節(jié)點片橡。
三、Session機制
3.1會話概述
?? 每個ZooKeeper客戶端的配置中都包括集合體中服務器的列表淮野。在啟動時捧书，客戶端會嘗試連接到列表中的一臺服務器。如果連接失敗骤星，它會嘗試連接另一臺服務器经瓷，以此類推，直到成功與一臺服務器建立連接或因為所有ZooKeeper服務器都不可用而失敗洞难。
?? 一旦客戶端與一臺ZooKeeper服務器建立連接舆吮，這臺服務器就會為該客戶端創(chuàng)建一個新的會話。
每個會話都會有一個超時的時間設置队贱，這個設置由創(chuàng)建會話的應用來設定色冀。如果服務器在超時時間段內(nèi)沒有收到任何請求，則相應的會話會過期柱嫌。一旦一個會話已經(jīng)過期锋恬，就無法重新打開，并且任何與該會話相關聯(lián)的短暫znode都會丟失编丘。會話通常長期存在与学，而且會話過期是一種比較罕見的事件彤悔，但對應用來說，如何處理會話過期仍是非常重要的癣防。?? 只要一個會話空閑超過一定時間蜗巧，都可以通過客戶端發(fā)送ping請求（也稱為心跳）保持會話不過期。ping請求由ZooKeeper的客戶端庫自動發(fā)送蕾盯，因此在我們的代碼中不需要考慮如何維護會話幕屹。這個時間長度的設置應當足夠低，以便能檔檢測出服務器故障（由讀超時體現(xiàn)）级遭，并且能夠在會話超時的時間段內(nèi)重新蓮接到另外一臺服務器望拖。
3.2 故障切換
ZooKeeper客戶端可以自動地進行故障切換，切換至另一臺ZooKeeper服務器挫鸽。并且關鍵的一點是说敏，在另一臺服務器接替故障服務器之后，所有的會話和相關的短暫Znode仍然是有效的丢郊。在故障切換過程中盔沫，應用程序將收到斷開連接和連接至服務的通知。當客戶端斷開連接時枫匾，觀察通知將無法發(fā)送架诞；但是當客戶端成功恢復連接后，這些延遲的通知會被發(fā)送干茉。當然谴忧，在客戶端重新連接至另一臺服務器的過程中，如果應用程序試圖執(zhí)行一個操作角虫，這個操作將會失敗沾谓。這充分體現(xiàn)了在真實的ZooKeeper應用中處理連接丟失異常的重要性。
四戳鹅、 Watch機制
?? Zookeeper客戶端在數(shù)據(jù)節(jié)點上設置監(jiān)視均驶，則當數(shù)據(jù)節(jié)點發(fā)生變化時，客戶端會收到提醒枫虏。ZooKeeper中的各種讀請求辣恋，如getDate()，getChildren()模软，和exists()伟骨，都可以選擇加"監(jiān)視點"(watch)。"監(jiān)視點"指的是一種一次性的觸發(fā)器(trigger)燃异，當受監(jiān)視的數(shù)據(jù)發(fā)生變化時携狭，該觸發(fā)器會通知客戶端。
(1) 監(jiān)視機制有三個關鍵點：
① "監(jiān)視點"是一次性的回俐，當觸發(fā)一次之后逛腿，除非重新設置稀并，新的數(shù)據(jù)變化不會提醒客戶端
② "監(jiān)視點"將數(shù)據(jù)改變通知客戶端。如果數(shù)據(jù)改變是客戶端A引起的单默，不能保證"監(jiān)視點"通知事件會在引發(fā)數(shù)據(jù)修改的函數(shù)返回前到達客戶端A碘举。
③ 對于"監(jiān)視點"，ZooKeeper有如下保證：
客戶端一定是在接收到"監(jiān)視"事件（watch event）之后才接收到數(shù)據(jù)的改變信息搁廓。
(3) ZooKeeper的"監(jiān)視"機制保證以下幾點：
① "監(jiān)視"事件的觸發(fā)順序和事件的分發(fā)順序一致引颈。
② 客戶端將先接收到"監(jiān)視"事件，然后才收到新的數(shù)據(jù)
③ "監(jiān)視"事件觸發(fā)的順序與ZooKeeper服務器上數(shù)據(jù)變化的順序一致
(4) 關于ZooKeeper"監(jiān)視"機制的注意點：
① "監(jiān)視點"是一次性的境蜕。
② 由于"監(jiān)視點"是一次性的蝙场，而且，從接收到"監(jiān)視"事件到設置新"監(jiān)視點"是有延時的粱年，所以客戶端可能監(jiān)控不到數(shù)據(jù)的所有變化售滤。
③ 一個監(jiān)控對象，只會被相關的通知觸發(fā)一次台诗。如果一個客戶端設置了關于某個數(shù)據(jù)點exists和getData的監(jiān)控完箩，
則當該數(shù)據(jù)被刪除的時候，只會觸發(fā)"文件被刪除"的通知拉队。
④ 當客戶端斷開與服務器的連接時弊知，客戶端不再能收到"監(jiān)視"事件，直到重新獲得連接氏仗。所以關于Session的信息將被發(fā)送給所有ZooKeeper服務器吉捶。
由于當連接斷開時收不到"監(jiān)視"夺鲜，所以在這種情況下皆尔，模塊行為需要容錯方面的設計。
