NameNode和SecondaryNameNode工作機制

• 1.簡單介紹
• 2.圖解
• 2.1原理介紹
• 2.2流程介紹
• 2.2.1 第一階段 NameNode啟動
• 2.2.2 第二階段 Secondary NameNode工作

1.簡單介紹

眾所周知NameNode記錄著DataNode的元資料資訊，那麼他是如何保證元資料資訊的準確性的呢！小小透露一下是通過Fsimage和Edits!

2.圖解

2.1原理介紹

NameNode啟動時，先滾動Edits並生成一個空的edits.inprogress，然後載入Edits和Fsimage到記憶體中，此時NameNode記憶體就持有最新的元資料資訊

。Client開始對NameNode傳送元資料的增刪改的請求，這些請求的操作首先會被記錄到edits.inprogress中（查詢元資料的操作不會被記錄在Edits中，因為查詢操作不會更改元資料資訊），如果此時NameNode掛掉，重啟後會從Edits中讀取元資料的資訊。然後，NameNode會在記憶體中執行元資料的增刪改的操作。由於Edits中記錄的操作會越來越多，Edits檔案會越來越大，導致NameNode在啟動載入Edits時會很慢，所以需要對Edits和Fsimage進行合併（所謂合併，就是將Edits和Fsimage載入到記憶體中，照著Edits中的操作一步步執行，最終形成新的Fsimage）。

1.看到這裡我相信很多人會問Edits 和Fsimage 究竟是什麼？好吧給你簡單的介紹下！
Fsimage：NameNode記憶體中元資料序列化後形成的檔案。
Edits：記錄客戶端更新元資料資訊的每一步操作（可通過Edits運算出元資料）。
2.你能看到的問題官方肯定也是看的到的啊！所以針對啟動載入慢的問題，也就出現了SecondaryNameNode，所以接下來我們來說一說SecondaryNameNode在幹嘛？有時怎麼幹的！

SecondaryNameNode首先會詢問NameNode是否需要CheckPoint（觸發CheckPoint需要滿足兩個條件中的任意一個，定時時間到和Edits中資料寫滿了）

。 如果需要，則首先會讓NameNode滾動Edits並生成一個空的edits.inprogress，滾動Edits的目的是給Edits打個標記，以後所有新的操作都寫入edits.inprogress，其他未合併的Edits和Fsimage會拷貝到SecondaryNameNode的本地，然後將拷貝的Edits和Fsimage載入到記憶體中進行合併，生成fsimage.chkpoint，然後將fsimage.chkpoint拷貝給NameNode，重新命名為Fsimage後替換掉原來的Fsimage。NameNode在啟動時就只需要載入之前未合併的Edits和Fsimage即可，因為合併過的Edits中的元資料資訊已經被記錄在Fsimage中。（ok,大概也就是這樣的一個過程了！！！）
1.預設觸發條件1小時和100W次讀寫操作

2.2流程介紹

2.2.1 第一階段 NameNode啟動

1.第一次啟動NameNode格式化後，建立Fsimage和Edits檔案。如果不是第一次啟動，直接載入編輯日誌和映象檔案到記憶體。
2.客戶端對元資料進行增刪改的請求。
3.NameNode記錄操作日誌，更新滾動日誌。
4.NameNode在記憶體中對資料進行增刪改。

2.2.2 第二階段 Secondary NameNode工作

1.Secondary NameNode詢問NameNode是否需要CheckPoint。直接帶回NameNode檢查結果。
2.Secondary NameNode請求執行CheckPoint。
3.NameNode滾動正在寫的Edits日誌。
4.將滾動前的編輯日誌和映象檔案拷貝到Secondary NameNode。
5.Secondary NameNode載入編輯日誌和映象檔案到記憶體，併合並。
6.生成新的映象檔案fsimage.chkpoint。
7.拷貝fsimage.chkpoint到NameNode。
8.NameNode將fsimage.chkpoint重新命名成fsimage。

版權宣告：本部落格為記錄本人自學感悟，轉載需註明出處！
https://me.csdn.net/qq_39657909