歡迎關注個人微訊號：石杉的架構筆記（id：shishan100）
週一至週五早8點半！精品技術文章準時送上！
往期文章2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
目錄
一、前奏
二、HDFS的NameNode架構原理
一、前奏
Hadoop是目前大資料領域最主流的一套技術體系，包含了多種技術。
包括HDFS（分散式檔案系統），YARN（分散式資源排程系統），MapReduce（分散式計算系統），等等。
有些朋友可能聽說過Hadoop，但是卻不太清楚他到底是個什麼東西，這篇文章就用大白話給各位闡述一下。
假如你現在公司裡的資料都是放在MySQL裡的，那麼就全部放在一臺資料庫伺服器上，我們就假設這臺伺服器的磁碟空間有2T吧，大家先看下面這張圖。
現在問題來了，你不停的往這臺伺服器的MySQL裡放資料，結果資料量越來越大了，超過了2T的大小了，現在咋辦？
你說，我可以搞多臺MySQL資料庫伺服器，分庫分表啊！每臺伺服器放一部分資料不就得了。如上圖所示！
好，沒問題，那我們們搞3臺資料庫伺服器，3個MySQL例項，然後每臺伺服器都可以2T的資料。
現在我問你一個問題，所謂的大資料是在幹什麼？
我們來說一下大資料最初級的一個使用場景。假設你有一個電商網站，現在要把這個電商網站裡所有的使用者在頁面和APP上的點選、購買、瀏覽的行為日誌都存放起來分析。
你現在把這些資料全都放在了3臺MySQL伺服器，資料量很大，但還是勉強可以放的下。
某天早上，你的boss來了。要看一張報表，比如要看每天網站的X指標、Y指標、Z指標，等等，二三十個資料指標。
好了，兄弟，現在你嘗試去從那些點選、購買、瀏覽的日誌裡，通過寫一個SQL來分析出那二三十個指標試試看？
我跟你打賭，你絕對會寫出來一個幾百行起步，甚至上千行的超級複雜大SQL。這個SQL，你覺得他能執行在分庫分表後的3臺MySQL伺服器上麼？
如果你覺得可以的話，那你一定是不太瞭解MySQL分庫分表後有多坑，幾百行的大SQL跨庫join，各種複雜的計算，根本不現實。
所以說，大資料的儲存和計算壓根兒不是靠MySQL來搞的，因此，Hadoop、Spark等大資料技術體系才應運而生。
本質上，Hadoop、Spark等大資料技術，其實就是一系列的分散式系統。
比如hadoop中的HDFS，就是大資料技術體系中的核心基石，負責分散式儲存資料，這是啥意思？別急，繼續往下看。
HDFS全稱是Hadoop Distributed File System，是Hadoop的分散式檔案系統。
它由很多機器組成，每臺機器上執行一個DataNode程式，負責管理一部分資料。
然後有一臺機器上執行了NameNode程式，NameNode大致可以認為是負責管理整個HDFS叢集的這麼一個程式，他裡面儲存了HDFS叢集的所有後設資料。
然後有很多臺機器，每臺機器儲存一部分資料！好，HDFS現在可以很好的儲存和管理大量的資料了。
這時候你肯定會有疑問：MySQL伺服器也不是這樣的嗎？你要是這樣想，那就大錯特錯了。
這個事情不是你想的那麼簡單的，HDFS天然就是分散式的技術，所以你上傳大量資料，儲存資料，管理資料，天然就可以用HDFS來做。
如果你硬要基於MySQL分庫分表這個事兒，會痛苦很多倍，因為MySQL並不是設計為分散式系統架構的，他在分散式資料儲存這塊缺乏很多資料保障的機制。
好，你現在用HDFS分散式儲存了資料，接著不就是要分散式來計算這些資料了嗎？
對於分散式計算：
- 很多公司用Hive寫幾百行的大SQL（底層基於MapReduce）
- 也有很多公司開始慢慢的用Spark寫幾百行的大SQL（底層是Spark Core引擎）。
總之就是寫一個大SQL，人家會拆分為很多的計算任務，放到各個機器上去，每個計算任務就負責計算一小部分資料，這就是所謂的分散式計算。
這個，絕對比你針對分庫分表的MySQL來跑幾百行大SQL要靠譜的多。
對於上述所說，老規矩，同樣給大家來一張圖，大夥兒跟著圖來仔細捋一下整個過程。
二、HDFS的NameNode架構原理
好了，前奏鋪墊完之後，進入正題。本文其實主要就是討論一下HDFS叢集中的NameNode的核心架構原理。
NameNode有一個很核心的功能：管理整個HDFS叢集的後設資料，比如說檔案目錄樹、許可權的設定、副本數的設定，等等。
下面就用最典型的檔案目錄樹的維護，來給大家舉例說明，我們看看下面的圖。現在有一個客戶端系統要上傳一個1TB的大檔案到HDFS叢集裡。
此時他會先跟NameNode通訊，說：大哥，我想建立一個新的檔案，他的名字叫“/usr/hive/warehouse/access_20180101.log”，大小是1TB，你看行不？
然後NameNode就會在自己記憶體的檔案目錄樹裡，在指定的目錄下搞一個新的檔案物件，名字就是“access_20180101.log”。
這個檔案目錄樹不就是HDFS非常核心的一塊後設資料，維護了HDFS這個分散式檔案系統中，有哪些目錄，有哪些檔案，對不對？
但是有個問題，這個檔案目錄樹是在NameNode的記憶體裡的啊！
這可坑爹了，你把重要的後設資料都放在記憶體裡，萬一NameNode不小心當機了可咋整？後設資料不就全部丟失了？
可你要是每次都頻繁的修改磁碟檔案裡的後設資料，效能肯定是極低的啊！畢竟這是大量的磁碟隨機讀寫！
沒關係，我們來看看HDFS優雅的解決方案。
每次記憶體裡改完了，寫一條edits log，後設資料修改的操作日誌到磁碟檔案裡，不修改磁碟檔案內容，就是順序追加，這個效能就高多了。
每次NameNode重啟的時候，把edits log裡的操作日誌讀到記憶體裡回放一下，不就可以恢復後設資料了？
大家順著上面的文字，把整個過程，用下面這張圖跟著走一遍。
但是問題又來了，那edits log如果越來越大的話，豈不是每次重啟都會很慢？因為要讀取大量的edits log回放恢復後設資料！
所以HDFS說，我可以這樣子啊，我引入一個新的磁碟檔案叫做fsimage，然後呢，再引入一個JournalNodes叢集，以及一個Standby NameNode（備節點）。
每次Active NameNode（主節點）修改一次後設資料都會生成一條edits log，除了寫入本地磁碟檔案，還會寫入JournalNodes叢集。
然後Standby NameNode就可以從JournalNodes叢集拉取edits log，應用到自己記憶體的檔案目錄樹裡，跟Active NameNode保持一致。
然後每隔一段時間，Standby NameNode都把自己記憶體裡的檔案目錄樹寫一份到磁碟上的fsimage，這可不是日誌，這是完整的一份後設資料。這個操作就是所謂的checkpoint檢查點操作。
然後把這個fsimage上傳到到Active NameNode，接著清空掉Active NameNode的舊的edits log檔案，這裡可能都有100萬行修改日誌了！
然後Active NameNode繼續接收修改後設資料的請求，再寫入edits log，寫了一小會兒，這裡可能就幾十行修改日誌而已！
如果說此時，Active NameNode重啟了，bingo！沒關係，只要把Standby NameNode傳過來的fsimage直接讀到記憶體裡，這個fsimage直接就是後設資料，不需要做任何額外操作，純讀取，效率很高！
然後把新的edits log裡少量的幾十行的修改日誌回放到記憶體裡就ok了！
這個過程的啟動速度就快的多了！因為不需要回放大量上百萬行的edits log來恢復後設資料了！如下圖所示。
此外，大家看看上面這張圖，現在我們們有倆NameNode。
- 一個是主節點對外提供服務接收請求
- 另外一個純就是接收和同步主節點的edits log以及執行定期checkpoint的備節點。
大家有沒有發現！他們倆記憶體裡的後設資料幾乎是一模一樣的啊！
所以呢，如果Active NameNode掛了，是不是可以立馬切換成Standby NameNode對外提供服務？
這不就是所謂的NameNode主備高可用故障轉移機制麼！
接下來大家再想想，HDFS客戶端在NameNode記憶體裡的檔案目錄樹，新加了一個檔案。
但是這個時候，人家要把資料上傳到多臺DataNode機器上去啊，這可是一個1TB的大檔案！咋傳呢？
很簡單，把1TB的大檔案拆成N個block，每個block是128MB。1TB = 1024GB = 1048576MB，一個block是128MB，那麼就是對應著8192個block。
這些block會分佈在不同的機器上管理著，比如說一共有100臺機器組成的叢集，那麼每臺機器上放80個左右的block就ok了。
但是問題又來了，那如果這個時候1臺機器當機了，不就導致80個block丟失了？
也就是說上傳上去的1TB的大檔案，會丟失一小部分資料啊。沒關係！HDFS都考慮好了！
它會預設給每個block搞3個副本，一模一樣的副本，分放在不同的機器上，如果一臺機器當機了，同一個block還有另外兩個副本在其他機器上呢！
大夥兒看看下面這張圖。每個block都在不同的機器上有3個副本，任何一臺機器當機都沒事！還可以從其他的機器上拿到那個block。
這下子，你往HDFS上傳一個1TB的大檔案，可以高枕無憂了吧！
OK，上面就是大白話加上一系列手繪圖，給大家先聊聊小白都能聽懂的Hadoop的基本架構原理
接下來會給大家聊聊HDFS，這個作為世界上最優秀的分散式儲存系統，承載高併發請求、高效能檔案上傳的一些核心機制以及原理。
《大規模叢集下Hadoop如何承載每秒上千次的高併發訪問》，敬請期待
《【冰山下的祕密】Hadoop如何將TB級大檔案的上傳效能提升上百倍？》，敬請期待
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上,
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授