1、zookeeper　

　　①背景：
　　　　Zookeeper 最早起源于雅虎研究院的一個研究小組。在當時，研究人員發現，在雅虎內部很多大型系統基本都需要依賴一個類似的系統來進行分布式協調，
　　　　但是這些系統往往都存在分布式單點問題。所以，
　　　　雅虎的開發人員就試圖開發一個通用的無單點問題的分布式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。

　　①定義：Zookeeper是一個開源的分布式協調框架（主要用來解決分布式環境當中多個進程之間的同步控制，讓他們有序的去訪問某種臨界資源）

　　③角色：

　　　　1）領導者（Leader） ： 處理所有請求，為客戶的提供讀和寫服務
　　　　2）跟隨者（Follower） ： 只提供讀服務，有機會通過選舉成為leader
　　　　3）觀察者（Observer）： 只提供讀服務 ，不參與投票，沒機會成為leader

　　　　注：由角色可以看出，即便是你對Follower進行寫操作，但是它不會寫，而是會將請求轉發給leader，待leader寫成功之后，再同步給其余角色。

　　④特點：

　　　　1） Zookeeper的集群中必須保證半數以上的節點存活才能對外提供服務器
　　　　2) Zookeeper在更新數據的時候存在一個特性：原子性 （數據要么所有角色全部更新成功，要么全部失敗）

　　⑤Master選舉：

　　　　解決問題：單點故障（幾個節點向Zookeeper進行注冊，Zookeeper通過選舉，得出領導者，如果領導者出現故障，重新選舉）

　　　　選舉規則：集群（5個）啟動時，當啟動到第3個時（過半數），找到這三個節點的myid,id最大的那個就是領導者，其余啟動的都是跟隨者。

　　　　第二次選舉規則：第二次選舉的時候由于已經存在了數據，則根據節點中數據版本最新的為主。

2、HA

　　1、QJM

　　　　Qurom Journal Manager：解決單點故障問題，即引入雙NameNode架構，同時借助共享存儲系統來進行元數據的同步。

　　　　RPC: 遠程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。

　　　　Qurom ：Zookeeper分布式協調服務。

　　　　Journal Node：存儲編輯日志，多個Journal Node通過Zookeeper實現共享存儲系統。

　　　　Standby NameNode：備份狀態的NN

　　　　Active NameNode: 啟動狀態的NN

　　　　ZKFC(單獨進程，每個NN都有)：

　　　　　　a.監控NN的健康狀態
　　　　　　b.向ZK定期發送心跳，使自己可以被選舉,當自己被ZK選為主時，active FailoverController通過RPC調用使相應的NN轉換為active
　　　　　　c.自動備援

　　2、架構原理：

　　　　先找到三個節點（Journal Node），然后通過Zookeeper的Qurom（分布式協調服務），實現Journal Node上存儲的編輯日志同步。
　　　　以上就是一個共享存儲系統，而名稱集群就是共享存儲系統所覆蓋的幾個節點，每個NN都有一個ZKFC，用以解決單點故障。

　　　　運行過程：

　　　　　　①client向Active NN提交操作，先向Active NN中的編輯日志中寫。
　　　　　　②如果成功，Active NN會修改元數據，并且Active NN向所有Journal Node請求寫編輯日志，只要將請求發給了其中任意一臺機器，則表示成功。 （由角色的定義可以看出）

　　　　　　③Standby NameNode 會一直監控JournalNode節點上的編輯日志，當發現編輯日志有所改變后會讀取這些編輯日志并合并到自己的namespace中。
　　　　　　④為了盡量減少故障切換所消耗的時間，DataNode會定時向所有NameNode節點發送塊的位置信息和心跳

　　　　注：外部訪問hdfs變成了名稱集群（此處命名MyNNS）

　　　　注：Journal Node + Qurom <==> 共享存儲系統

?

轉載于:https://www.cnblogs.com/lihaozong2013/p/10625483.html

總結

以上是生活随笔為你收集整理的2-zookeeper、ha的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。