歷史

ZooKeeper原本是Apache Hadoop的一個組件(Hadoop 的分布式協(xié)調(diào)服務(wù))败玉，是Google的Chubby一個開源的實現(xiàn)蛀恩，現(xiàn)在被拆分為一個Hadoop的獨立子項目

設(shè)計初衷

ZooKeeper的設(shè)計目的疫铜，是為了減輕分布式應(yīng)用程序所承擔(dān)的協(xié)調(diào)任務(wù)，用來建立安全處理局部故障的分布式應(yīng)用双谆，它本身并不能阻止局部故障的發(fā)生

數(shù)據(jù)模型和實現(xiàn)

ZooKeeper本質(zhì)上是通過一個類似標準文件系統(tǒng)的共享層次命名空間來實現(xiàn)分布式進程間的協(xié)調(diào)壳咕，由于是類文件系統(tǒng)，所以即使所有的ZooKeeper節(jié)點全部掛掉顽馋，數(shù)據(jù)也不會丟失谓厘，重啟服務(wù)器之后，數(shù)據(jù)即可恢復(fù)寸谜。其中命名空間節(jié)點被稱作znode竟稳，znode節(jié)點可以包含數(shù)據(jù)和孩子節(jié)點，和標準文件系統(tǒng)不一樣的是ZooKeeper把數(shù)據(jù)保存在內(nèi)存當(dāng)中熊痴，因為在內(nèi)存中讀寫數(shù)據(jù)他爸，所以ZooKeeper可以保證高吞吐和低延時性。節(jié)點更新是原子的果善，也就是說更新不是成功就是失敗

兩種特殊的ZNode

????1: Ephemeral Nodes：Ephemeral節(jié)點在創(chuàng)建它的會話活動期間存在讲逛。會話終止的時候，臨時節(jié)點被刪除岭埠，所以臨時節(jié)點不能有子節(jié)點。(應(yīng)用：集群管理)

????2: Sequence Nodes：創(chuàng)建znode時，可以要求ZooKeeper在路徑名后增加一個單調(diào)增加的計數(shù)器部分惜论。這個計數(shù)器相對于znode的父節(jié)點是唯一的许赃。計數(shù)器的格式是%010d，例如：0000000001馆类。(應(yīng)用：分布式鎖混聊，選舉)

一致性

ZooKeeper采用的是ZAB (ZooKeeper Atomic Broadcast)?一致性算法

一般來說，我們說的一致性分為如下多種

????1: 強一致性（strong consistency）: 任何時刻乾巧，任何用戶都能讀取到最近一次成功更新的數(shù)據(jù)句喜。

????2: 單調(diào)一致性（monotonic consistency）: 任何時刻，任何用戶一旦讀到某個數(shù)據(jù)在某次更新后的值沟于，那么就不會再讀到比這個值更舊的值咳胃。也就是說，可獲取的數(shù)據(jù)順序必是單調(diào)遞增的旷太。

? ? 3: 會話一致性（session consistency）: 任何用戶在某次會話中展懈，一旦讀到某個數(shù)據(jù)在某次更新后的值，那么在本次會話中就不會再讀到比這值更舊的值供璧。會話一致性是在單調(diào)一致性的基礎(chǔ)上進一步放松約束存崖，只保證單個用戶單個會話內(nèi)的單調(diào)性，在不同用戶或同一用戶不同會話間則沒有保障睡毒。

? ? 4: 最終一致性（eventual consistency）: 用戶只能讀到某次更新后的值来惧，但系統(tǒng)保證數(shù)據(jù)將最終達到完全一致的狀態(tài)，只是所需時間不能保障演顾。

? ? 5: 弱一致性（weak consistency）: 用戶無法在確定時間內(nèi)讀到最新更新的值供搀。

ZooKeeper的讀寫數(shù)據(jù)流(多節(jié)點讀，一個master節(jié)點負責(zé)寫偶房，寫完之后各個節(jié)點自己同步)

? ? 1: 寫: Client => Follower => Leader => Follower => Client

????2: 讀: Client => Follower => Client

可以很清楚的看到趁曼，在集群中寫數(shù)據(jù)的時候，存在數(shù)據(jù)并沒有在集群中完成寫入棕洋，集群數(shù)據(jù)還未同步挡闰，就已經(jīng)更新了命名空間。這個時候使用最新的名稱去讀取數(shù)據(jù)會讀到錯誤的數(shù)據(jù)掰盘，解決數(shù)據(jù)不同步問題摄悯，只能通過同步機制（定時執(zhí)行sync()方法）解決

ZooKeeper的一致性

? ? 1: 同一session：順序一致性，保證版本不會退愧捕；

? ? 2: 跨session：最終一致性奢驯，你最終會讀到新數(shù)據(jù)的；

提供的服務(wù)

? ? 1: 統(tǒng)一命名服務(wù)

? ? 2: 配置管理

? ? 3: 集群管理

? ? 4: 共享鎖和隊列管理

統(tǒng)一命名服務(wù):通過指定的名字獲取資源或者服務(wù)提供者的信息

Zookeeper提供統(tǒng)一的命名服務(wù)次绘，他不對外提供數(shù)據(jù)也不存儲數(shù)據(jù)瘪阁，他只提供一套統(tǒng)一的命名規(guī)則撒遣，運行在Zookeeper之上的服務(wù)需要遵循這一套命名規(guī)則

配置管理：配置的管理包含發(fā)布和訂閱兩個過程，將數(shù)據(jù)發(fā)布到ZK節(jié)點上管跺，供訂閱者動態(tài)獲取數(shù)據(jù)义黎，實現(xiàn)配置信息的集中管理和動態(tài)更新

集群管理：集群監(jiān)控和Leader選舉

傳統(tǒng)的集群監(jiān)控是通過某種手段（比如 ping）定是檢測，或者機器定時向監(jiān)控系統(tǒng)匯報

ZooKeeper的做法是

????1: 客戶端在示例節(jié)點A上注冊一個監(jiān)控者（Watcher）豁跑，那么如果A的子節(jié)點變化了廉涕，會通知該客戶端。

? ? 2: 創(chuàng)建EPHEMERAL類型的節(jié)點艇拍，一旦客戶端和服務(wù)器的會話結(jié)束或過期狐蜕，那么該節(jié)點就會消失。?

共享鎖和隊列管理:?利用zookeeper對znode節(jié)點操作的原子性

總結(jié)

ZooKeeper可以

? ? 1: 順序一致性：來自于客戶端的更新卸夕，根據(jù)發(fā)送的先后被順序?qū)嵤?/p>

? ? 2: 唯一的系統(tǒng)映像：盡管客戶端連接到不同的服務(wù)器层释，但它們看到的一個唯一（一致性）的系統(tǒng)服務(wù)，client無論連接到哪個server娇哆，數(shù)據(jù)視圖都是一致的湃累。

? ? 3: 可靠性：一旦實施了一個更新，就會一直保持那種狀態(tài)碍讨，直到客戶端再次更新它治力，同時數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功勃黍，要么失敗宵统。

? ? 4: 及時性：在一個確定的時間內(nèi)，客戶端看到的系統(tǒng)狀態(tài)是最新的覆获。

ZooKeeper不可以

? ? 1: 實時性：如果需要最新數(shù)據(jù)马澈，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口

? ? 2: 所有數(shù)據(jù)，都存儲在內(nèi)存中弄息，導(dǎo)致不能存儲太多的數(shù)據(jù)

? ? 3: 慢