1 Hadoop 系統架構
1.1 Hadoop1.x和Hadoop2.x 架構
在介紹HA之前，我們先來看下Hadoop的系統架構，這對於理解HA是至關重要的，Hadoop
1.x之前，其官方架構如圖1所示:
[ 圖1.Hadoop 1.x架構圖 ]
從圖中可看出，1.x版本之前只有一個Namenode,所有元數據由惟一的Namenode負責管理,可想而之當這個NameNode掛掉時整個集群基本也就不可用。
Hadoop 2.x的架構與1.x有什么區別呢。我們來看下2.x的架構：
[ 圖2.Hadoop 2.x架構圖 ]
2.x版本中，HDFS架構解決了單點故障問題，即引入雙NameNode架構，同時借助共享存儲系統來進行元數據的同步，共享存儲系統類型一般有幾類，如：Shared
NAS+NFS、BookKeeper、BackupNode 和 Quorum Journal
Manager(QJM)，上圖中用的是QJM作為共享存儲組件，通過搭建奇數結點的JournalNode實現主備NameNode元數據操作信息同步。
Hadoop的元數據包括哪些信息呢，下面介紹下關於元數據方面的知識。
1.2 Hadoop 2.x元數據
Hadoop的元數據主要作用是維護HDFS文件系統中文件和目錄相關信息
元數據的存儲形式主要有3類：內存鏡像、磁盤鏡像(FSImage)、日志(EditLog)。
-
在Namenode啟動時，會加載磁盤鏡像到內存中以進行元數據的管理，存儲在NameNode內存；
-
磁盤鏡像是某一時刻HDFS的元數據信息的快照，包含所有相關Datanode節點文件塊映射關系和命名空間(Namespace)信息，存儲在NameNode本地文件系統；
-
日志文件記錄client發起的每一次操作信息，即保存所有對文件系統的修改操作，用於定期和磁盤鏡像合並成最新鏡像，保證NameNode元數據信息的完整，存儲在NameNode本地和共享存儲系統(QJM)中。
-
如下所示為NameNode本地的EditLog和FSImage文件格式，EditLog文件有兩種狀態：
inprocess和finalized,
inprocess表示正在寫的日志文件，文件名形式:editsinprocess[start-txid] -
finalized表示已經寫完的日志文件,文件名形式：edits*[start-txid]*[end-txid]；
FSImage文件也有兩種狀態, finalized和checkpoint，
finalized表示已經持久化磁盤的文件，文件名形式: fsimage_[end-txid],
checkpoint表示合並中的fsimage -
2.x版本checkpoint過程在Standby
Namenode(SNN)上進行，SNN會定期將本地FSImage和從QJM上拉回的ANN的EditLog進行合並，合並完后再通過RPC傳回ANN。
data/hbase/runtime/namespace
├── current
│ ├── VERSION
│ ├── edits_0000000003619794209-0000000003619813881
│ ├── edits_0000000003619813882-0000000003619831665
│ ├── edits_0000000003619831666-0000000003619852153
│ ├── edits_0000000003619852154-0000000003619871027
│ ├── edits_0000000003619871028-0000000003619880765
│ ├── edits_0000000003619880766-0000000003620060869
│ ├── edits_inprogress_0000000003620060870
│ ├── fsimage_0000000003618370058
│ ├── fsimage_0000000003618370058.md5
│ ├── fsimage_0000000003620060869
│ ├── fsimage_0000000003620060869.md5
│ └── seen_txid
└── in_use.lock
-
上面所示的還有一個很重要的文件就是seen_txid,保存的是一個事務ID，這個事務ID是EditLog最新的一個結束事務id，當NameNode重啟時，會順序遍歷從edits_0000000000000000001到seen_txid所記錄的txid所在的日志文件，進行元數據恢復，如果該文件丟失或記錄的事務ID有問題，會造成數據塊信息的丟失。
-
HA其本質上就是要保證主備NN元數據是保持一致的，即保證fsimage和editlog在備NN上也是完整的。元數據的同步很大程度取決於EditLog的同步，而這步驟的關鍵就是共享文件系統，下面開始介紹一下關於QJM共享存儲機制。
2 Hadoop的HA機制
前言：正式引入HA機制是從hadoop2.0開始，之前的版本中沒有HA機制
1.1 HA的運作機制
（1）hadoop-HA集群運作機制介紹
所謂HA，即高可用（7*24小時不中斷服務）,實現高可用最關鍵的是消除單點故障
hadoop-ha嚴格來說應該分成各個組件的HA機制——HDFS的HA、YARN的HA
（2）HDFS的HA機制詳解
通過雙namenode消除單點故障,雙namenode協調工作的要點：
A、元數據管理方式需要改變：
(1)內存中各自保存一份元數據
(2)Edits日志只能有一份，只有Active狀態的namenode節點可以做寫操作
(3)兩個namenode都可以讀取edits
(4)共享的edits放在一個共享存儲中管理（qjournal和NFS兩個主流實現）
B、需要一個狀態管理功能模塊
(1)實現了一個zkfailover，常駐在每一個namenode所在的節點
(2)每一個zkfailover負責監控自己所在namenode節點，利用zk進行狀態標識
(3)當需要進行狀態切換時，由zkfailover來負責切換
(4)切換時需要防止brain split現象的發生
1.2 HDFS-HA圖解：
