大規模集群下的Hadoop NameNode
本文我們來看看,如果大量客戶端對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處理高並發訪問修改元數據的能力!
TAG:千鋒JAVA開發學院 |