大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

石杉的架構筆記發表於2018-11-15

歡迎關注個人公眾號:石杉的架構筆記(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,會咋樣?


大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問


不用說,這個絕對完蛋了!

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。

大家可能感覺文字敘述不太直觀,老規矩,我們們來一張圖,按順序給大家闡述一下。


大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問


(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級大檔案的上傳效能提升上百倍?》敬請期待

如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!

一大波微服務、分散式、高併發、高可用原創系列

文章正在路上,歡迎掃描下方二維碼,持續關注:

大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

石杉的架構筆記(id:shishan100)

十餘年BAT架構經驗傾囊相授


相關文章