今天扣丁學堂大數據培訓老師給大家介紹一下關於大數據開發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的單點問題
以上就是關於扣丁學堂大數據開發Zookeeper集群管理與選舉的詳細介紹，扣丁學習提供在線從零到一的大數據視頻教程共學員免費在線觀看，其內容包含Linux&&Hadoop生態體系、大數據計算框架體系、雲計算體系、機器學習&&深度學習，扣丁學堂大數據學習群：209080834。
標籤: 大數據培訓 大數據視頻教程 大數據分析培訓 大數據學習視頻 Hadoop生態圈
閱讀更多 扣丁學堂 的文章
