本文來源于公衆号【胖滾豬學程式設計】，轉載請注明出處。
本文整合梳理了主流大資料生态圈中的元件：Hdfs+Yarn+HBase+Spark+Storm的單點故障問題的解決方案：建構HA（High Available）高可用架構。閱讀本文之前，最好需要了解清楚各元件的架構原理。
首先一張圖來了解下這些元件的架構：
我們可以發現：它們的共同特點就是都是主從結構。HDFS中的NameNode,Yarn中ResourceManager,Hbase中HMaster,Spark中Master,Storm中Nimbus起着“老大”的角色，那麼“老大”挂了怎麼辦呢？這可就麻煩了，隻要老大挂了，等于整個叢集的服務都用不了了，NameNode挂了整個叢集的HDFS就用不了了，HBase的HMaster挂了整個叢集的Hbase都用不了了，等等。這就是所謂的單點故障問題。單點指隻有一個主節點。
既然隻有一個主節點就會發生單點故障，那麼我們很容易可以想到，我來兩個不就行了！對的，HA的思想就是多弄幾個主節點，一個死了另一個上。但這樣也不夠啊！必須有個東西能夠使得發生故障的時候自動切換啊！這東西就是Zookeeper。是以有了下面這張圖：
由于這些元件的HA原理類似，我們隻以最難的HDFS的HA高可用架構原理為例講解。而其他元件，不講解原理，隻上配置檔案。
Zookeeper是一個開源的分布式協調服務，分布式應用程式可以基于ZooKeeper實作諸如資料釋出/訂閱、負載均衡、命名服務、分布式協調/通知、叢集管理、Master選舉、分布式鎖和分布式隊列等功能。
ZK在Hadoop生态圈中的主要功能有：
選舉功能，比如HDFS中Active NameNode的選舉、YARN中Active ResourceManager的選舉和HBase中Active HMaster的選舉。
ZooKeeper具有在各個節點同步資料的功能，能保證高度的一緻性，是以它能夠保證在任何時候隻有一個節點為Active。
ZooKeeper分布式協調/通知功能，可用于心跳檢測，不同程序之間需要檢測到彼此是否在正常運作，比如HDFS中NameNode需要知道DataNode是否正常。基本原理是建立一個臨時znode，如果連接配接逾時就删除這個節點，不同的程序直接可以根據這個臨時子節點來判斷對應的程序是否存活。
namenode職責：
（1）負責用戶端的請求和響應
（2）負責中繼資料的管理（查詢，修改。。）
（3）維護元資訊（fsimage檔案），fsimage是磁盤中繼資料鏡像檔案，存儲中繼資料資訊。
（4）維護記錄檔（edits檔案），edits是資料記錄檔檔案，當用戶端操作檔案的時候，操作記錄首先會被記錄到edits日志檔案中。
我們可以在$dfs.namenode.name.dir/current目錄下看到如下的檔案結構
出現HA之後，(3)和(4)交給了另一個叫做JournalNode的東東。JournalNode在HA故障轉移中起到了重要的作用！
在兩個NN（NameNode簡寫，下同）間選舉出一個Active NN，Active NN會在ZK上建立臨時節點Znode
兩個NN都會向ZK發送心跳檢測資訊，讓ZK實時知道它們的狀态。
任何修改操作在 Active NN上執行時，JN程序同時也會記錄修改log到至少半數以上的JN中，這時 Standby NN 監測到JN 裡面的同步log發生變化了會讀取 JN 裡面的修改log，然後同步到自己的的目錄鏡像樹裡面。
Active NN挂了之後，連接配接逾時，ZK收不到心跳資訊了，就把對應的臨時znode進行删除，znode的删除事件會主動觸發到下一次的Active NamNode的選擇。
原來的StandbyNN準備要上位了，它會在成為Active NN 前，讀取所有的JN裡面的日志，這樣就能高可靠的保證與挂掉的NN的目錄鏡像樹一緻，然後無縫的接替它的職責，維護來自用戶端請求，進而達到一個高可用的目的。
注：故障切換是通過ZKFC(FailOverController)完成。
core-site.xml
hdfs-site.xml
（1）啟動zookeeper叢集（分别在slave1、slave2和slave3上執行）
<code>zkServer.sh start</code>
（2）格式化ZKFC（在master1上執行）
<code>hdfs zkfc -formatZK</code>
（3）啟動journalnode（分别在slave1、slave2和slave3上執行）
<code>sbin/hadoop-daemon.sh start journalnode</code>
（4）格式化HDFS（在master1上執行）
<code>hdfs namenode -format</code>
（5）啟動nn1
<code>sbin/hadoop-daemon.sh start namenode</code>
（6）第二個namenode機器同步中繼資料資訊
<code>bin/hdfs namenode -bootstrapStandby</code>
（7）啟動nn2
（6）啟動所有datanode
<code>sbin/hadoop-daemons.sh start datanode</code>
（7）在master機器上先啟動zkfc（自動故障轉移） 它就變成active了 <code>sbin/hadoop-daemon.sh start zkfc</code>
（8）再在slave1機器上啟動zkfc.它就變成standby了
（1）啟動服務
（2）kill指令殺死active nn的程序
（3）在web UI界面上會發現Standby自動變成了Active
原理與HDFS的非常類似，也是通過Zookeeper心跳檢測，自動切換，非常簡單，就是配置一下配置檔案。
本文來源于公衆号【胖滾豬學程式設計】，一個集顔值與才華于一身的女程式媛，歡迎關注。
Hbase其實是無單點故障的，你可以手動啟動多個HMaster，比如在master機器上啟動hbase(<code>bin/start-hbase.sh</code>)之後，可以到slave1機器上也啟動master(<code>bin/hbase-daemon.sh start master</code>)，無需任何配置。但是手工啟動這樣有點麻煩，可以通過配置檔案，使得每次啟動hbase時候自動的幫你啟動兩個HMaster。
<code>touch backup-masters</code>在此檔案上輸入你要作為備份HMaster的機器主機名。
Spark同樣是用ZooKeeper來實作HA。ZooKeeper提供了一個Leader Election機制，由于ZK的高度一緻性，可以保證雖有多個Master但是隻有一個是Active的，當Active的Master出現故障時，另外的一個Standby Master會被選舉出來。
<code>vim conf/spark-env.sh</code>
注釋掉原本的SPARK_MASTER_HOST，如果它存在，就會預設隻以它為Master。
-Dspark.deploy.recoveryMode： 表明整個叢集的恢複和維護都是Zookeeper.
-Dspark.deploy.zookeeper.url: 所有做HA機器，其中端口2181是預設端口。
-Dspark.deploy.zookeeper.dir： 指定Spark在Zookeeper注冊的資訊
需要将它分發給需要做備份Master的機器。
<code>scp conf/spark-env.sh slave1:/usr/local/spark-2.2.0-bin-hadoop2.6.0-cdh5.11.1/conf/</code>
在一台機器上：<code>sbin/start-all.sh</code>
另一台機器上啟動第二個Master：<code>sbin/start-master.sh</code>