本文我們來看看，如果大量客戶端對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處理高并發訪問修改元數據的能力!