HDFS高可用性及其分佈式系統思想基礎

源自單點失效問題，也就是當NameNode不可用的時候，用什麼辦法能夠平滑過渡？

最直接的辦法是再添加一個備用的NN，這就產生了Active NameNode和Standby NameNode的設計思路。

接下來的一個問題是，如何讓Standby Namenode的文件系統命名空間元數據與Active NameNode 的一致呢？

目前的解決辦法有QJM方法和NFS方法。

QJM方案：添加多個Journal Node，這個數字是2F+1，經過Paxos協議保證數據的一致性，QJM最多可容忍F個JournalNode同時發生故障而系統仍然能夠正常運行。

還有一個問題是，當ANN出現了故障以後，如何自動切換？

目前採用的方案是使用zookeeper實現「領導選舉」。

參見下圖（圖片來自Linux公社）：

 

如今有這樣一個問題：

　　zookeeper如何實現「領導選舉」？

如下內容來自《大數據日知錄：架構與算法》一書。

Zookeeper在實現領導選舉時，實現方法參加以下python代碼：

　　ZookeeperLeaderElect.py

　　handle = zookeeper.init("localhost:2181",my_connection_watcher,10000,0);//初始化

　　(data,stat) = zookeeper.get(handle,"/services/myservice/leader",True)//獲取領導者節點信息

　　if(stat=None)

　　　　path = zookeeper.create(handle,"/services/myservice/leader",hostname:info,[ZOO_OPEN_ACL_UNSAFE],zookeeper.EPHEMERAL)

　　　　if (path==None)//說明建立leader路徑失敗，也就是說沒法將目前節點設置爲領導者節點，也就意味着在程序執行過程當中間，有其餘的節點的進程設置了leader節點

　　　　　　(data,stat) = zookeeper.get(handle,"services/myservice/leader",True)

　　　　　　#其餘服務器是領導者

　　　　　　#從leader節點讀取並解析領導者地址信息

　　　　else

　　　　　　#當前節點已經成功設置爲領導者節點

　　　else

　　　　#其餘服務器是領導者

　　　　#從leader節點讀取並解析領導者地址信息