建站
咨詢
售后
建站咨詢
新聞中心
一、寫在前面
上篇文章我們已經(jīng)初步給大家解釋了Hadoop HDFS的整體架構(gòu)原理，相信大家都有了一定的認(rèn)識和了解。
創(chuàng)新互聯(lián)專注于北海網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供北海營銷型網(wǎng)站建設(shè)，北海網(wǎng)站制作、北海網(wǎng)頁設(shè)計、北海網(wǎng)站官網(wǎng)定制、成都小程序開發(fā)服務(wù)，打造北海網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供北海網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
如果沒看過上篇文章的同學(xué)可以看一下：《?干掉幾百行的大SQL，我用Hadoop?》這篇文章。
本文我們來看看，如果大量客戶端對NameNode發(fā)起高并發(fā)（比如每秒上千次）訪問來修改元數(shù)據(jù)，此時NameNode該如何抗??？
二、問題源起
我們先來分析一下，高并發(fā)請求NameNode會遇到什么樣的問題。
大家現(xiàn)在都知道了，每次請求NameNode修改一條元數(shù)據(jù)（比如說申請上傳一個文件，那么就需要在內(nèi)存目錄樹中加入一個文件），都要寫一條edits log，包括兩個步驟：
- 寫入本地磁盤。
- 通過網(wǎng)絡(luò)傳輸給JournalNodes集群。
但是如果對Java有一定了解的同學(xué)都該知道多線程并發(fā)安全問題吧？
NameNode在寫edits log時的第一條原則：
必須保證每條edits log都有一個全局順序遞增的transactionId（簡稱為txid），這樣才可以標(biāo)識出來一條一條的edits log的先后順序。
那么如果要保證每條edits log的txid都是遞增的，就必須得加鎖。
每個線程修改了元數(shù)據(jù)，要寫一條edits log的時候，都必須按順序排隊(duì)獲取鎖后，才能生成一個遞增的txid，代表這次要寫的edits log的序號。
好的，那么問題來了，大家看看下面的圖。
如果每次都是在一個加鎖的代碼塊里，生成txid，然后寫磁盤文件edits log，網(wǎng)絡(luò)請求寫入journalnodes一條edits log，會咋樣？
不用說，這個絕對完蛋了！
NameNode本身用多線程接收多個客戶端發(fā)送過來的并發(fā)的請求，結(jié)果多個線程居然修改完內(nèi)存中的元數(shù)據(jù)之后，排著隊(duì)寫edits log！
而且你要知道，寫本地磁盤 + 網(wǎng)絡(luò)傳輸給journalnodes，都是很耗時的??！性能兩大殺手：磁盤寫 + 網(wǎng)絡(luò)寫！
如果HDFS的架構(gòu)真要是這么設(shè)計的話，基本上NameNode能承載的每秒的并發(fā)數(shù)量就很少了，可能就每秒處理幾十個并發(fā)請求處理撐死了！
三、HDFS優(yōu)雅的解決方案
所以說，針對這個問題，人家HDFS是做了不少的優(yōu)化的！
首先大家想一下，既然咱們不希望每個線程寫edits log的時候，串行化排隊(duì)生成txid + 寫磁盤 + 寫JournalNode，那么是不是可以搞一個內(nèi)存緩沖？
也就是說，多個線程可以快速的獲取鎖，生成txid，然后快速的將edits log寫入內(nèi)存緩沖。
接著就快速的釋放鎖，讓下一個線程繼續(xù)獲取鎖后，生成id + 寫edits log進(jìn)入內(nèi)存緩沖。
然后接下來有一個線程可以將內(nèi)存中的edits log刷入磁盤，但是在這個過程中，還是繼續(xù)允許其他線程將edits log寫入內(nèi)存緩沖中。
?但是這里又有一個問題了，如果針對同一塊內(nèi)存緩沖，同時有人寫入，還同時有人讀取后寫磁盤，那也有問題，因?yàn)椴荒懿l(fā)讀寫一塊共享內(nèi)存數(shù)據(jù)！
所以HDFS在這里采取了double-buffer雙緩沖機(jī)制來處理！將一塊內(nèi)存緩沖分成兩個部分：?
- 其中一個部分可以寫入
- 另外一個部分用于讀取后寫入磁盤和JournalNodes。
大家可能感覺文字?jǐn)⑹霾惶庇^，老規(guī)矩，咱們來一張圖，按順序給大家闡述一下。
1、分段加鎖機(jī)制 + 內(nèi)存雙緩沖機(jī)制
首先各個線程依次第一次獲取鎖，生成順序遞增的txid，然后將edits log寫入內(nèi)存雙緩沖的區(qū)域1，接著就立馬第一次釋放鎖了。
趁著這個空隙，后面的線程就可以再次立馬第一次獲取鎖，然后立即寫自己的edits log到內(nèi)存緩沖。
寫內(nèi)存那么快，可能才耗時幾十微妙，接著就立馬第一次釋放鎖了。所以這個并發(fā)優(yōu)化絕對是有效果的，大家有沒有感受到？
接著各個線程競爭第二次獲取鎖，有線程獲取到鎖之后，就看看，有沒有誰在寫磁盤和網(wǎng)絡(luò)？
如果沒有，好，那么這個線程是個幸運(yùn)兒！直接交換雙緩沖的區(qū)域1和區(qū)域2，接著第二次釋放鎖。這個過程相當(dāng)快速，內(nèi)存里判斷幾個條件，耗時不了幾微秒。
好，到這一步為止，內(nèi)存緩沖已經(jīng)被交換了，后面的線程可以立馬快速的依次獲取鎖，然后將edits log寫入內(nèi)存緩沖的區(qū)域2，區(qū)域1中的數(shù)據(jù)被鎖定了，不能寫。
怎么樣，是不是又感受到了一點(diǎn)點(diǎn)多線程并發(fā)的優(yōu)化？
2、多線程并發(fā)吞吐量的百倍優(yōu)化
接著，之前那個幸運(yùn)兒線程，將內(nèi)存緩沖的區(qū)域1中的數(shù)據(jù)讀取出來（此時沒人寫區(qū)域1了，都在寫區(qū)域2），將里面的edtis log都寫入磁盤文件，以及通過網(wǎng)絡(luò)寫入JournalNodes集群。
這個過程可是很耗時的！但是沒關(guān)系啊，人家做過優(yōu)化了，在寫磁盤和網(wǎng)絡(luò)的過程中，是不持有鎖的！
因此后面的線程可以噼里啪啦的快速的第一次獲取鎖后，立馬寫入內(nèi)存緩沖的區(qū)域2，然后釋放鎖。
這個時候大量的線程都可以快速的寫入內(nèi)存，沒有阻塞和卡頓！
怎么樣？并發(fā)優(yōu)化的感覺感受到了沒有！
3、緩沖數(shù)據(jù)批量刷磁盤 + 網(wǎng)絡(luò)的優(yōu)化
?那么在幸運(yùn)兒線程吭哧吭哧把數(shù)據(jù)寫磁盤和網(wǎng)絡(luò)的過程中，排在后面的大量線程，快速的第一次獲取鎖，寫內(nèi)存緩沖區(qū)域2，釋放鎖，之后，這些線程第二次獲取到鎖后會干嘛？
他們會發(fā)現(xiàn)有人在寫磁盤啊，兄弟們！所以會立即休眠1秒，釋放鎖。
此時大量的線程并發(fā)過來的話，都會在這里快速的第二次獲取鎖，然后發(fā)現(xiàn)有人在寫磁盤和網(wǎng)絡(luò)，快速的釋放鎖，休眠。
怎么樣，這個過程沒有人長時間的阻塞其他人吧！因?yàn)槎紩焖俚尼尫沛i，所以后面的線程還是可以迅速的第一次獲取鎖后寫內(nèi)存緩沖！
again！并發(fā)優(yōu)化的感覺感受到了沒有？?
而且這時，一定會有很多線程發(fā)現(xiàn)，好像之前那個幸運(yùn)兒線程的txid是排在自己之后的，那么肯定就把自己的edits log從緩沖里寫入磁盤和網(wǎng)絡(luò)了。
這些線程甚至都不會休眠等待，直接就會返回后去干別的事情了，壓根兒不會卡在這里。這里又感受到并發(fā)的優(yōu)化沒有？
然后那個幸運(yùn)兒線程寫完磁盤和網(wǎng)絡(luò)之后，就會喚醒之前休眠的那些線程。
那些線程會依次排隊(duì)再第二次獲取鎖后進(jìn)入判斷，咦！發(fā)現(xiàn)沒有人在寫磁盤和網(wǎng)絡(luò)了！
然后就會再判斷，有沒有排在自己之后的線程已經(jīng)將自己的edtis log寫入磁盤和網(wǎng)絡(luò)了。
- 如果有的話，就直接返回了。
- 沒有的話，那么就成為第二個幸運(yùn)兒線程，交換兩塊緩沖區(qū)，區(qū)域1和區(qū)域2交換一下。
- 然后釋放鎖，自己開始吭哧吭哧的將區(qū)域2的數(shù)據(jù)寫入磁盤和網(wǎng)絡(luò)。
但是這個時候沒有關(guān)系啊，后面的線程如果要寫edits log的，還是可以第一次獲取鎖后立馬寫內(nèi)存緩沖再釋放鎖。以此類推。
四、總結(jié)
?其實(shí)這套機(jī)制還是挺復(fù)雜的，涉及到了分段加鎖以及內(nèi)存雙緩沖兩個機(jī)制。
通過這套機(jī)制，NameNode保證了多個線程在高并發(fā)的修改元數(shù)據(jù)之后寫edits log的時候，不會說一個線程一個線程的寫磁盤和網(wǎng)絡(luò)，那樣性能實(shí)在太差，并發(fā)能力太弱了！
所以通過上述那套復(fù)雜的機(jī)制，盡最大的努力保證，一個線程可以批量的將一個緩沖中的多條edits log刷入磁盤和網(wǎng)絡(luò)。
在這個漫長的吭哧吭哧的過程中，其他的線程可以快速的高并發(fā)寫入edits log到內(nèi)存緩沖里，不會阻塞其他的線程寫edits log。
所以，正是依靠以上機(jī)制，最大限度優(yōu)化了NameNode處理高并發(fā)訪問修改元數(shù)據(jù)的能力！?
當(dāng)前題目：每秒上千次高并發(fā)訪問，HDFS優(yōu)雅的抗住了
文章鏈接：http://www.5511xx.com/article/cdcjjgs.html
