好程序員大數據分享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的單點問題

 

　　學習大數據開發，能夠參考好程序員提供的大數據學習路線，該學習路線提供完整的大數據開發知識體系，內容包含Linux&&Hadoop生態體系、大數據計算框架體系、雲計算體系、機器學習&&深度學習。根據好程序員提供的大數據學習路線圖可讓你對學習大數據須要掌握的知識有個清晰的瞭解，並快速入門大數據開發。