【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

歡迎關注微信公衆號：石杉的架構筆記（id：shishan100）

個人新課**《C2C 電商系統微服務架構120天實戰訓練營》在公衆號儒猿技術窩**上線了，感興趣的同窗，能夠點擊下方連接瞭解詳情：

《C2C 電商系統微服務架構120天實戰訓練營》

目錄

1、前情概要

2、背景引入

3、問題凸現

4、Hadoop的優化方案

1、前情概要

這篇文章給你們聊聊Hadoop在部署了大規模的集羣場景下，大量客戶端併發寫數據的時候，文件契約監控算法的性能優化。看懂這篇文章須要一些Hadoop的基礎知識背景，還不太瞭解的兄弟，能夠先看看以前的文章：兄弟，用大白話告訴你小白都能看懂的Hadoop架構原理。

2、背景引入

先給你們引入一個小的背景，假如多個客戶端同時要併發的寫Hadoop HDFS上的一個文件，你們以爲這個事兒能成嗎？

明顯不能夠接受啊，兄弟們，HDFS上的文件是不容許併發寫的，好比並發的追加一些數據什麼的。因此說，HDFS裏有一個機制，叫作文件契約機制。

也就是說，同一時間只能有一個客戶端獲取NameNode上面一個文件的契約，而後才能夠寫入數據。此時若是其餘客戶端嘗試獲取文件契約的時候，就獲取不到，只能乾等着。經過這個機制，就能夠保證同一時間只有一個客戶端在寫一個文件。

在獲取到了文件契約以後，在寫文件的過程期間，那個客戶端須要**開啓一個線程，不停的發送請求給NameNode進行文件續約，告訴NameNode：大哥，我還在寫文件啊，你給我一直保留那個契約好嗎？而NameNode內部有一個專門的後臺線程，負責監控各個契約的續約時間。**若是某個契約很長時間沒續約了，此時就自動過時掉這個契約，讓別的客戶端來寫。

說了這麼多，老規矩，給你們來一張圖，直觀的感覺一下整個過程。

3、問題凸現

好，那麼如今問題來了，假如咱們有一個大規模部署的Hadoop集羣，同時存在的客戶端可能多達成千上萬個。此時NameNode內部維護的那個文件契約列表會很是很是的大，而監控契約的後臺線程又須要頻繁的每隔一段時間就檢查一下全部的契約是否過時。

好比，每隔幾秒鐘就遍歷大量的契約，那麼勢必形成性能不佳，因此說這種契約監控機制明顯是不適合大規模部署的hadoop集羣的。

4、Hadoop的優化方案

那麼Hadoop是如何對文件契約監控算法進行優化的呢？我們來一步一步的看一下他的實現邏輯。首先，咱們一塊兒來看看下面這張手繪圖：

其實奧祕十分的簡單，每次一個客戶端發送續約請求以後，就設置這個契約的最近一次續約時間。而後，基於一個TreeSet數據結構來根據最近一次續約時間對契約進行排序，每次都把續約時間最老的契約排在最前頭，這個排序後的契約數據結構十分的重要。

TreeSet是一種可排序的數據結構，他底層基於TreeMap來實現。TreeMap底層則基於紅黑樹來實現，能夠保證元素沒有重複，同時還能按照咱們本身定義的排序規則在你每次插入一個元素的時候來進行自定義的排序。因此這裏咱們的排序規則：就是按照契約的最近一次續約時間來排序。

其實這個優化就是如此的簡單，就是維護這麼一個排序數據結構而已。咱們如今來看一下Hadoop中的契約監控的源碼實現：

每次檢查契約是否過時的時候，你不要遍歷成千上萬的契約，那樣遍歷效率固然會很低下。咱們徹底能夠就從TreeSet中獲取續約時間最老的那個契約，假如說連最近一次續約時間最老的那個契約都還沒過時，那麼就不用繼續檢查了啊！這說明續約時間更近的那些契約絕對不會過時！

舉個例子：續約時間最老的那個契約，最近一次續約的時間是10分鐘之前，可是咱們判斷契約過時的限制是超過15分鐘不續約就過時那個契約。這個時候，連10分鐘之前續約的契約都沒有過時，那麼那些8分鐘之前，5分鐘之前續約的契約，確定也不會過時啊！

這個機制的優化對性能的提高是至關有幫助的，由於正常來講，過時的契約確定仍是佔少數，因此壓根兒不用每次都遍歷全部的契約來檢查是否過時。咱們只須要檢查續約時間最舊的那幾個契約就能夠了，若是一個契約過時了，那麼就刪掉那個契約，而後再檢查第二舊的契約好了。以此類推。

經過這個TreeSet排序 + 優先檢查最舊契約的機制，有效的將大規模集羣下的契約監控機制的性能提高至少10倍以上，這種思想是很是值得咱們學習和借鑑的。

給你們稍微引伸一下，在Spring Cloud微服務架構中，Eureka做爲註冊中心其實也有續約檢查的機制，跟Hadoop是相似的（若是想了解Eureka註冊中心相關技術的朋友，建議看一下：《拜託！面試請不要再問我Spring Cloud底層原理！》）。可是在Eureka中就沒有實現相似的續約優化機制，而是暴力的每一輪都遍歷全部的服務實例的續約時間。

若是你面對的是一個大規模部署的微服務系統呢，狀況就不妙了！

部署了幾十萬臺機器的大規模系統，有幾十萬個服務實例的續約信息駐留在Eureka的內存中，難道每隔幾秒鐘都要遍歷幾十萬個服務實例的續約信息嗎？

最後給你們提一句，優秀的開源項目，蘊含着不少優秀的設計思想。多看各類優秀開源項目的源碼，是短期內快速、大幅度提高一我的的技術功底和技術水平的方式，你們不妨嘗試一下。

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

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

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

石杉的架構筆記（id:shishan100）

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

**推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

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

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！**