歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至五早8點半！精品技術文章準時送上！
往期文章
目錄
一、寫在前面
二、問題源起
三、HDFS優雅的解決方案：
（1）分段加鎖機制+記憶體雙緩衝機制
（2）多執行緒併發吞吐量的百倍優化
（3）緩衝資料批量刷磁碟+網路優化
一、寫在前面
上篇文章我們已經初步給大家解釋了Hadoop HDFS的整體架構原理，相信大家都有了一定的認識和了解。
如果沒看過上篇文章的同學可以看一下：《兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理》這篇文章。
本文我們來看看，如果大量客戶端對NameNode發起高併發（比如每秒上千次）訪問來修改後設資料，此時NameNode該如何抗住？
二、問題源起
我們先來分析一下，高併發請求NameNode會遇到什麼樣的問題。
大家現在都知道了，每次請求NameNode修改一條後設資料（比如說申請上傳一個檔案，那麼就需要在記憶體目錄樹中加入一個檔案），都要寫一條edits log，包括兩個步驟：
寫入本地磁碟。
通過網路傳輸給JournalNodes叢集。
但是如果對Java有一定了解的同學都該知道多執行緒併發安全問題吧？
NameNode在寫edits log時的第一條原則：
必須保證每條edits log都有一個全域性順序遞增的transactionId（簡稱為txid），這樣才可以標識出來一條一條的edits log的先後順序。
那麼如果要保證每條edits log的txid都是遞增的，就必須得加鎖。
每個執行緒修改了後設資料，要寫一條edits log的時候，都必須按順序排隊獲取鎖後，才能生成一個遞增的txid，代表這次要寫的edits log的序號。
好的，那麼問題來了，大家看看下面的圖。
如果每次都是在一個加鎖的程式碼塊裡，生成txid，然後寫磁碟檔案edits log，網路請求寫入journalnodes一條edits log，會咋樣？
不用說，這個絕對完蛋了！
NameNode本身用多執行緒接收多個客戶端傳送過來的併發的請求，結果多個執行緒居然修改完記憶體中的後設資料之後，排著隊寫edits log！
而且你要知道，寫本地磁碟 + 網路傳輸給journalnodes，都是很耗時的啊！效能兩大殺手：磁碟寫 + 網路寫！
如果HDFS的架構真要是這麼設計的話，基本上NameNode能承載的每秒的併發數量就很少了，可能就每秒處理幾十個併發請求處理撐死了！
三、HDFS優雅的解決方案
所以說，針對這個問題，人家HDFS是做了不少的優化的！
首先大家想一下，既然我們們不希望每個執行緒寫edits log的時候，序列化排隊生成txid + 寫磁碟 + 寫JournalNode，那麼是不是可以搞一個記憶體緩衝？
也就是說，多個執行緒可以快速的獲取鎖，生成txid，然後快速的將edits log寫入記憶體緩衝。
接著就快速的釋放鎖，讓下一個執行緒繼續獲取鎖後，生成id + 寫edits log進入記憶體緩衝。
然後接下來有一個執行緒可以將記憶體中的edits log刷入磁碟，但是在這個過程中，還是繼續允許其他執行緒將edits log寫入記憶體緩衝中。
但是這裡又有一個問題了，如果針對同一塊記憶體緩衝，同時有人寫入，還同時有人讀取後寫磁碟，那也有問題，因為不能併發讀寫一塊共享記憶體資料！
所以HDFS在這裡採取了double-buffer雙緩衝機制來處理！將一塊記憶體緩衝分成兩個部分：
其中一個部分可以寫入
另外一個部分用於讀取後寫入磁碟和JournalNodes。
大家可能感覺文字敘述不太直觀，老規矩，我們們來一張圖，按順序給大家闡述一下。
（1）分段加鎖機制 + 記憶體雙緩衝機制
首先各個執行緒依次第一次獲取鎖，生成順序遞增的txid，然後將edits log寫入記憶體雙緩衝的區域1，接著就立馬第一次釋放鎖了。
趁著這個空隙，後面的執行緒就可以再次立馬第一次獲取鎖，然後立即寫自己的edits log到記憶體緩衝。
寫記憶體那麼快，可能才耗時幾十微妙，接著就立馬第一次釋放鎖了。所以這個併發優化絕對是有效果的，大家有沒有感受到？
接著各個執行緒競爭第二次獲取鎖，有執行緒獲取到鎖之後，就看看，有沒有誰在寫磁碟和網路？
如果沒有，好，那麼這個執行緒是個幸運兒！直接交換雙緩衝的區域1和區域2，接著第二次釋放鎖。這個過程相當快速，記憶體裡判斷幾個條件，耗時不了幾微秒。
好，到這一步為止，記憶體緩衝已經被交換了，後面的執行緒可以立馬快速的依次獲取鎖，然後將edits log寫入記憶體緩衝的區域2，區域1中的資料被鎖定了，不能寫。
怎麼樣，是不是又感受到了一點點多執行緒併發的優化？
（2）多執行緒併發吞吐量的百倍優化
接著，之前那個幸運兒執行緒，將記憶體緩衝的區域1中的資料讀取出來（此時沒人寫區域1了，都在寫區域2），將裡面的edtis log都寫入磁碟檔案，以及通過網路寫入JournalNodes叢集。
這個過程可是很耗時的！但是沒關係啊，人家做過優化了，在寫磁碟和網路的過程中，是不持有鎖的！
因此後面的執行緒可以噼裡啪啦的快速的第一次獲取鎖後，立馬寫入記憶體緩衝的區域2，然後釋放鎖。
這個時候大量的執行緒都可以快速的寫入記憶體，沒有阻塞和卡頓！
怎麼樣？併發優化的感覺感受到了沒有！
（3）緩衝資料批量刷磁碟 + 網路的優化
那麼在幸運兒執行緒吭哧吭哧把資料寫磁碟和網路的過程中，排在後面的大量執行緒，快速的第一次獲取鎖，寫記憶體緩衝區域2，釋放鎖，之後，這些執行緒第二次獲取到鎖後會幹嘛？
他們會發現有人在寫磁碟啊，兄弟們！所以會立即休眠1秒，釋放鎖。
此時大量的執行緒併發過來的話，都會在這裡快速的第二次獲取鎖，然後發現有人在寫磁碟和網路，快速的釋放鎖，休眠。
怎麼樣，這個過程沒有人長時間的阻塞其他人吧！因為都會快速的釋放鎖，所以後面的執行緒還是可以迅速的第一次獲取鎖後寫記憶體緩衝！
again！併發優化的感覺感受到了沒有？
而且這時，一定會有很多執行緒發現，好像之前那個幸運兒執行緒的txid是排在自己之後的，那麼肯定就把自己的edits log從緩衝裡寫入磁碟和網路了。
這些執行緒甚至都不會休眠等待，直接就會返回後去幹別的事情了，壓根兒不會卡在這裡。這裡又感受到併發的優化沒有？
然後那個幸運兒執行緒寫完磁碟和網路之後，就會喚醒之前休眠的那些執行緒。
那些執行緒會依次排隊再第二次獲取鎖後進入判斷，咦！發現沒有人在寫磁碟和網路了！
然後就會再判斷，有沒有排在自己之後的執行緒已經將自己的edtis log寫入磁碟和網路了。
如果有的話，就直接返回了。
沒有的話，那麼就成為第二個幸運兒執行緒，交換兩塊緩衝區，區域1和區域2交換一下。
然後釋放鎖，自己開始吭哧吭哧的將區域2的資料寫入磁碟和網路。
但是這個時候沒有關係啊，後面的執行緒如果要寫edits log的，還是可以第一次獲取鎖後立馬寫記憶體緩衝再釋放鎖。以此類推。
四、總結
其實這套機制還是挺複雜的，涉及到了分段加鎖以及記憶體雙緩衝兩個機制。
通過這套機制，NameNode保證了多個執行緒在高併發的修改後設資料之後寫edits log的時候，不會說一個執行緒一個執行緒的寫磁碟和網路，那樣效能實在太差，併發能力太弱了！
所以通過上述那套複雜的機制，盡最大的努力保證，一個執行緒可以批量的將一個緩衝中的多條edits log刷入磁碟和網路。
在這個漫長的吭哧吭哧的過程中，其他的執行緒可以快速的高併發寫入edits log到記憶體緩衝裡，不會阻塞其他的執行緒寫edits log。
所以，正是依靠以上機制，最大限度優化了NameNode處理高併發訪問修改後設資料的能力！
END
《【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能提升上百倍？》，敬請期待
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列
文章正在路上,歡迎掃描下方二維碼，持續關注：石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授