zookeeper 簡介
提供的主要功 能包括：配置管理、名字服務(wù)、分布式鎖、集群管理
特點(diǎn)
1.一個(gè)leader 多個(gè) follower 組成的 集群
2.集群有半數(shù)以上 存活 集群可用
3.全局?jǐn)?shù)據(jù)一致：每個(gè)server 都備份數(shù)據(jù) ，每個(gè)節(jié)點(diǎn)的數(shù)據(jù) 都一樣
4.更新請求順序進(jìn)行：針對每個(gè)client 更新請求 按照順序執(zhí)行
5.數(shù)據(jù)更新 原子性：一個(gè)更新操作 要么成功 要么失敗
6.實(shí)時(shí)性：在一定時(shí)間內(nèi)，client能讀到最新數(shù)據(jù)
ZooKeeper提供了什么？
1、文件系統(tǒng)
2、通知機(jī)制
Zookeeper文件系統(tǒng)
Zookeeper提供一個(gè)多層級的節(jié)點(diǎn)命名空間（節(jié)點(diǎn)稱為znode）。與文件系統(tǒng)不同的是，這些節(jié)點(diǎn)都可以設(shè)置關(guān)聯(lián)的數(shù)據(jù)，而文件系統(tǒng)中只有文件節(jié)點(diǎn)可以存放數(shù)據(jù)而目錄節(jié)點(diǎn)不行。
Zookeeper為了保證高吞吐和低延遲，在內(nèi)存中維護(hù)了這個(gè)樹狀的目錄結(jié)構(gòu)，這種特性使得Zookeeper不能用于存放大量的數(shù)據(jù)，每個(gè)節(jié)點(diǎn)的存放數(shù)據(jù)上限為1M。
ZAB協(xié)議？
ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)Zookeeper專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。
ZAB協(xié)議包括兩種基本的模式：崩潰恢復(fù)和消息廣播。
當(dāng)整個(gè)zookeeper集群剛剛啟動或者Leader服務(wù)器宕機(jī)、重啟或者網(wǎng)絡(luò)故障導(dǎo)致不存在過半的服務(wù)器與Leader服務(wù)器保持正常通信時(shí)，所有進(jìn)程（服務(wù)器）進(jìn)入崩潰恢復(fù)模式，首先選舉產(chǎn)生新的Leader服務(wù)器，然后集群中Follower服務(wù)器開始與新的Leader服務(wù)器進(jìn)行數(shù)據(jù)同步，當(dāng)集群中超過半數(shù)機(jī)器與該Leader服務(wù)器完成數(shù)據(jù)同步之后，退出恢復(fù)模式進(jìn)入消息廣播模式，Leader服務(wù)器開始接收客戶端的事務(wù)請求生成事物提案來進(jìn)行事務(wù)請求處理。
四種類型的數(shù)據(jù)節(jié)點(diǎn) Znode
PERSISTENT-持久節(jié)點(diǎn)
除非手動刪除，否則節(jié)點(diǎn)一直存在于Zookeeper上
EPHEMERAL-臨時(shí)節(jié)點(diǎn)
臨時(shí)節(jié)點(diǎn)的生命周期與客戶端會話綁定，一旦客戶端會話失效（客戶端與zookeeper連接斷開不一定會話失效），那么這個(gè)客戶端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會被移除。
PERSISTENT_SEQUENTIAL-持久順序節(jié)點(diǎn)
基本特性同持久節(jié)點(diǎn)，只是增加了順序?qū)傩?，?jié)點(diǎn)名后邊會追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。
EPHEMERAL_SEQUENTIAL-臨時(shí)順序節(jié)點(diǎn)
基本特性同臨時(shí)節(jié)點(diǎn)，增加了順序?qū)傩?，?jié)點(diǎn)名后邊會追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。
Zookeeper Watcher 機(jī)制 -- 數(shù)據(jù)變更通知
Zookeeper允許客戶端向服務(wù)端的某個(gè)Znode注冊一個(gè)Watcher監(jiān)聽，當(dāng)服務(wù)端的一些指定事件觸發(fā)了這個(gè)Watcher，服務(wù)端會向指定客戶端發(fā)送一個(gè)事件通知來實(shí)現(xiàn)分布式的通知功能，然后客戶端根據(jù)Watcher通知狀態(tài)和事件類型做出業(yè)務(wù)上的改變。
工作機(jī)制：
客戶端注冊watcher
服務(wù)端處理watcher
客戶端回調(diào)watcher
Watcher特性總結(jié)：
- 一次性
無論是服務(wù)端還是客戶端，一旦一個(gè)Watcher被觸發(fā)，Zookeeper都會將其從相應(yīng)的存儲中移除。這樣的設(shè)計(jì)有效的減輕了服務(wù)端的壓力，不然對于更新非常頻繁的節(jié)點(diǎn)，服務(wù)端會不斷的向客戶端發(fā)送事件通知，無論對于網(wǎng)絡(luò)還是服務(wù)端的壓力都非常大。 - 客戶端串行執(zhí)行
客戶端Watcher回調(diào)的過程是一個(gè)串行同步的過程。 - 輕量
- Watcher通知非常簡單，只會告訴客戶端發(fā)生了事件，而不會說明事件的具體內(nèi)容。
- 客戶端向服務(wù)端注冊Watcher的時(shí)候，并不會把客戶端真實(shí)的Watcher對象實(shí)體傳遞到服務(wù)端，僅僅是在客戶端請求中使用boolean類型屬性進(jìn)行了標(biāo)記。
- watcher event異步發(fā)送watcher的通知事件從server發(fā)送到client是異步的，這就存在一個(gè)問題，不同的客戶端和服務(wù)器之間通過socket進(jìn)行通信，由于網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶端在不通的時(shí)刻監(jiān)聽到事件，由于Zookeeper本身提供了ordering guarantee，即客戶端監(jiān)聽事件后，才會感知它所監(jiān)視znode發(fā)生了變化。所以我們使用Zookeeper不能期望能夠監(jiān)控到節(jié)點(diǎn)每次的變化。Zookeeper只能保證最終的一致性，而無法保證強(qiáng)一致性。
- 注冊watcher getData、exists、getChildren
- 觸發(fā)watcher create、delete、setData
- 當(dāng)一個(gè)客戶端連接到一個(gè)新的服務(wù)器上時(shí)，watch將會被以任意會話事件觸發(fā)。當(dāng)與一個(gè)服務(wù)器失去連接的時(shí)候，是無法接收到watch的。而當(dāng)client重新連接時(shí)，如果需要的話，所有先前注冊過的watch，都會被重新注冊。通常這是完全透明的。只有在一個(gè)特殊情況下，watch可能會丟失：對于一個(gè)未創(chuàng)建的znode的exist watch，如果在客戶端斷開連接期間被創(chuàng)建了，并且隨后在客戶端連接上之前又刪除了，這種情況下，這個(gè)watch事件可能會被丟失。
