思考：NameNode中的元數據是存儲在哪裏的？
首先，我們做個假設，如果存儲在NameNode節點的磁盤中，因爲經常需要進行隨機訪問，還有響應客戶請求，必然是效率過低。因此，元數據需要存放在內存中。但如果只存在內存中，一旦斷電，元數據丟失，整個集羣就無法工作了。因此產生在磁盤中備份元數據的FsImage。
這樣又會帶來新的問題，當在內存中的元數據更新時，如果同時更新FsImage，就會導致效率過低，但如果不更新，就會發生一致性問題，一旦NameNode節點斷電，就會產生數據丟失。因此，引入Edits文件(只進行追加操作，效率很高)。每當元數據有更新或者添加元數據時，修改內存中的元數據並追加到Edits中。這樣，一旦NameNode節點斷電，可以通過FsImage和Edits的合併，合成元數據。
但是，如果長時間添加數據到Edits中，會導致該文件數據過大，效率降低，而且一旦斷電，恢復元數據需要的時間過長。因此，需要定期進行FsImage和Edits的合併，如果這個操作由NameNode節點完成，又會效率過低。因此，引入一個新的節點SecondaryNamenode，專門用於FsImage和Edits的合併。
1. 第一階段：NameNode啓動
（1）第一次啓動NameNode格式化後，創建Fsimage和Edits文件。如果不是第一次啓動，直接加載編輯日誌和鏡像文件到內存。
（2）客戶端對元數據進行增刪改的請求。
（3）NameNode記錄操作日誌，更新滾動日誌。
（4）NameNode在內存中對數據進行增刪改。
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。
NN和2NN工作機制詳解：
Fsimage：NameNode內存中元數據序列化後形成的文件。
Edits：記錄客戶端更新元數據信息的每一步操作（可通過Edits運算出元數據）。
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）。SecondaryNameNode的作用就是幫助NameNode進行Edits和Fsimage的合併工作。
SecondaryNameNode首先會詢問NameNode是否需要CheckPoint（觸發CheckPoint需要滿足兩個條件中的任意一個，定時時間到和Edits中數據寫滿了）。直接帶回NameNode是否檢查結果。SecondaryNameNode執行CheckPoint操作，首先會讓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中。