1. hadoop中HDFS的NameNode原理
1.1. 組成
- 包括HDFS（分布式文件系統），YARN（分布式資源調度系統），MapReduce（分布式計算系統），等等。
1.2. HDFS架構原理
- 比如現在要上傳一個1T的大文件，提交給HDFS的
Active NameNode（用以存放文件目錄樹，權限設置，副本數設置等），它會在指定目錄下創建一個新的文件對象，比如access_20180101.log - 至於具體數據，它會將它拆分后進行分布式存儲，分散在各個DataNode節點，且默認都會有3個副本，防止其中一台機器宕機使得數據缺失
- 這里圖之所以這么復雜，原因在於大量的請求提交給
Active NameNode會不斷修改元數據，而元數據是在內存的，為了防止宕機丟失，必須把它存在磁盤，但是頻繁的修改磁盤數據，性能是很低的，這是大量的磁盤隨機讀寫，所以有了上述圖的方案 - 每次操作請求
Active NameNode會寫一條edits log放到磁盤文件，不是直接修改磁盤文件內容，而是順序追加，這個性能就高多了 - 同時它會把
edits log還會寫入JournalNodes集群，通過JournalNodes會把操作日志傳到Standby NameNode，這就相當於是個備份服務，確保了Standby NameNode內存中的元數據和Active NameNode是一樣的，而Standby NameNode每隔一段時間會把內存里的元數據寫一份到磁盤的fsimage文件，這個文件就是全量的元數據了，不是日志記錄 - 再然后會把這個fsimage上傳到
Active NameNode，替換掉內存中的元數據，再清空掉Active NameNode所在磁盤上的edits log，重新開始記錄日志 - 為什么要這么做？因為為了防止
Active NameNode突然宕機后，我們需要進行恢復，它的恢復是基於磁盤上的edits log的，和redis的aof相同的道理，它需要重新運行一遍日志中的所有命令，當時間長了后日志可能會很大，重啟時間也就會很長； - 引入
Standby NameNode的備份機制，就可以在節點重啟時，直接從Standby NameNode的fsimage讀取元數據備份，這就相當於redis的rdb恢復，速度是比較快的，讀取完備份再從磁盤的edits log讀取少量的操作日志執行恢復，就完全恢復到宕機前的狀態了
1.3. NameNode如何承載每秒上千次的高並發訪問
- 分段加鎖機制+內存雙緩沖機制（老實說我是沒看懂，他的博客我也留言問了兩個問題，有能看懂了拜托這里留言或在他博客
過眼雲煙本尊這個評論者下留言，Thanks♪(･ω･)ﾉ） - 我特別不懂的地方就是既要保證順序性，為什么還能用多線程並發？
參考：
用大白話告訴你小白都能看懂的Hadoop架構原理
大規模集群下Hadoop NameNode如何承載每秒上千次的高並發訪問