好程式設計師大資料技術分享Zookeeper叢集管理與選舉

大資料技術的學習，逐漸成為很多程式設計師的必修課，同時也出現了很多技術論壇供大家探討，所以今天 好程式設計師分享大資料技術 Zookeeper 叢集管理與選舉，大家可以一起學習 !

 

　　1. 叢集機器監控

 

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

 

　　叢集中機器有變動的時候，牽連修改的東西比較多。

 

　　有一定的延時。

 

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

 

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

 

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

 

　　例如，監控系統在 /clusterServers 節點上註冊一個 Watcher ，以後每動態加機器，那麼就往 /clusterServers 下建立一個 EPHEMERAL 型別的節點： /clusterServers/{hostname}. 這樣，監控系統就能夠實時知道機器的增減情況，至於後續處理就是監控系統的業務了。

 

　　2.Master 選舉

 

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

 

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

 

　　另外，這種場景演化一下，就是動態 Master 選舉。這就要用到 ?EPHEMERAL_SEQUENTIAL 型別節點的特性了。

 

上文中提到，所有客戶端建立請求，最終只有一個能夠建立成功。在這裡稍微變化下，就是允許所有請求都能夠建立成功，但是得有個建立順序，於是所有的請求最終在 ZK 上建立結果的一種可能情況是這樣：

/currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3 … .. 每次選取序列號最小的那個機器作為 Master ，如果這個機器掛了，由於他建立的節點會馬上小時，那麼之後最小的那個機器就是 Master 了。

 

　　3. 搜尋系統

 

　　在搜尋系統中，如果叢集中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引資料一致。因此讓叢集中的 Master 來進行全量索引的生成，然後同步到叢集中其它機器。另外， Master 選舉的容災措施是，可以隨時進行手動指定 master ，就是說應用在 zk 在無法獲取 master 資訊時，可以透過比如 http 方式，向一個地方獲取 master 。

 

　　在 Hbase 中，也是使用 ZooKeeper 來實現動態 HMaster 的選舉。在 Hbase 實現中，會在 ZK 上儲存一些 ROOT 表的地址和 HMaster 的地址， HRegionServer 也會把自己以臨時節點 (Ephemeral) 的方式註冊到 Zookeeper 中，使得 HMaster 可以隨時感知到各個 HRegionServer 的存活狀態，同時，一旦 HMaster 出現問題，會重新選舉出一個 HMaster 來執行，從而避免了 HMaster 的單點問題