一、叢集機器監控

這通常用於那種對叢集中機器狀態，機器線上率有較高要求的場景，能夠快速對叢集中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測叢集機器是否存活。過去的做法通常是：監控系統透過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統彙報"我還活著"。
這種做法可行，但是存在兩個比較明顯的問題：

1. 叢集中機器有變動的時候，牽連修改的東西比較多。
2. 有一定的延時。

利用ZooKeeper中兩個特性，就可以實施另一種叢集機器存活性監控系統：

1. 客戶端在節點 x 上註冊一個Watcher，那麼如果 x 的子節點變化了，會通知該客戶端。

2. 建立EPHEMERAL型別的節點，一旦客戶端和伺服器的會話結束或過期，那麼該節點就會消失。

應用
應用叢集中，我們常常需要讓每一個機器知道叢集中或依賴的其他某一個叢集中哪些機器是活著的，並且在叢集機器因為當機，網路斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器，Zookeeper 能夠很容易的實現叢集管理的功能，如有多臺 Server 組成一個服務叢集，那麼必須要一個"總管"知道當前叢集中每臺機器的服務狀態，一旦有機器不能提供服務，叢集中其它叢集必須知道，從而做出調整重新分配服務策略。同樣當增加叢集的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓"總管"知道，這就是ZooKeeper的叢集監控功能。

比如我在zookeeper伺服器端有一個znode叫/Configuration，那麼叢集中每一個機器啟動的時候都去這個節點下建立一個EPHEMERAL型別的節點，比如server1建立/Configuration /Server1，server2建立/Configuration /Server1，然後Server1和Server2都watch /Configuration 這個父節點，那麼也就是這個父節點下資料或者子節點變化都會通知對該節點進行watch的客戶端。因為EPHEMERAL型別節點有一個很重要的特性，就是客戶端和伺服器端連線斷掉或者session過期就會使節點消失，那麼在某一個機器掛掉或者斷鏈的時候，其對應的節點就會消
失，然後叢集中所有對/Configuration進行watch的客戶端都會收到通知，然後取得最新列表即可。

二、Master選舉

Master選舉則是zookeeper中最為經典的使用場景了，在分散式環境中，相同的業務應用分佈在不同的機器上，有些業務邏輯，例如一些耗時的計算，網路I/O處，往往只需要讓整個叢集中的某一臺機器進行執行，其餘機器可以共享這個結果，這樣可以大大減少重複勞動，提高效能，於是這個master選舉便是這種場景下的碰到的主要問題。

利用ZooKeeper中兩個特性，就可以實施另一種叢集中Master選舉：

1. 利用ZooKeeper的強一致性，能夠保證在分散式高併發情況下節點建立的全域性唯一性，即：同時有多個客戶端請求建立 /Master 節點，最終一定只有一個客戶端請求能夠建立成功。利用這個特性，就能很輕易的在分散式環境中進行叢集選舉了。

2. 另外，這種場景演化一下，就是動態Master選舉。這就要用到 EPHEMERAL_SEQUENTIAL型別節點的特性了，這樣每個節點會自動被編號。允許所有請求都能夠建立成功，但是得有個建立順序，每次選取序列號最小的那個機器作為Master 。

應用
Zookeeper 不僅能夠維護當前的叢集中機器的服務狀態，而且能夠選出一個"總管"，讓這個總管來管理叢集，這就是 Zookeeper 的另一個功能 Leader Election。Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣每臺 Server 建立一個 EPHEMERAL 目錄節點，不同的是它還是一個 SEQUENTIAL 目錄節點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節點，是因為我們可以給每臺 Server 編號，我們可以選擇當前是最小編號的 Server 為 Master，假如這個最小編號的 Server 死去，由於是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，所以當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點為當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。

Zookeeper應用場景之【叢集管理】

相關文章