一、前情概要

這篇文章給大家聊聊Hadoop在部署了大規(guī)模的集群場景下，大量客戶端并發(fā)寫數(shù)據(jù)的時候，文件契約監(jiān)控算法的性能優(yōu)化。

二、背景引入

先給大家引入一個小的背景，假如多個客戶端同時要并發(fā)的寫Hadoop HDFS上的一個文件，大家覺得這個事兒能成嗎？

明顯不可以接受啊，兄弟們，HDFS上的文件是不允許并發(fā)寫的，比如并發(fā)的追加一些數(shù)據(jù)什么的。

所以說，HDFS里有一個機制，叫做文件契約機制。

也就是說，同一時間只能有一個客戶端獲取NameNode上面一個文件的契約，然后才可以寫入數(shù)據(jù)。此時如果其他客戶端嘗試獲取文件契約的時候，就獲取不到，只能干等著。

通過這個機制，就可以保證同一時間只有一個客戶端在寫一個文件。

在獲取到了文件契約之后，在寫文件的過程期間，那個客戶端需要開啟一個線程，不停的發(fā)送請求給NameNode進行文件續(xù)約，告訴NameNode：

NameNode大哥，我還在寫文件啊，你給我一直保留那個契約好嗎？

而NameNode內(nèi)部有一個專門的后臺線程，負責監(jiān)控各個契約的續(xù)約時間。

如果某個契約很長時間沒續(xù)約了，此時就自動過期掉這個契約，讓別的客戶端來寫。

說了這么多，老規(guī)矩，給大家來一張圖，直觀的感受一下整個過程。

三、問題凸現(xiàn)

好，那么現(xiàn)在問題來了，假如我們有一個大規(guī)模部署的Hadoop集群，同時存在的客戶端可能多達成千上萬個。

此時NameNode內(nèi)部維護的那個文件契約列表會非常非常的大，而監(jiān)控契約的后臺線程又需要頻繁的每隔一段時間就檢查一下所有的契約是否過期。

比如，每隔幾秒鐘就遍歷大量的契約，那么勢必造成性能不佳，所以說這種契約監(jiān)控機制明顯是不適合大規(guī)模部署的hadoop集群的。

四、Hadoop的優(yōu)化方案

那么Hadoop是如何對文件契約監(jiān)控算法進行優(yōu)化的呢？咱們來一步一步的看一下他的實現(xiàn)邏輯。

首先，我們一起來看看下面這張手繪圖：

其實奧秘十分的簡單，每次一個客戶端發(fā)送續(xù)約請求之后，就設置這個契約的最近一次續(xù)約時間。

然后，基于一個TreeSet數(shù)據(jù)結構來根據(jù)最近一次續(xù)約時間對契約進行排序，每次都把續(xù)約時間最老的契約排在最前頭，這個排序后的契約數(shù)據(jù)結構十分的重要。

TreeSet是一種可排序的數(shù)據(jù)結構，他底層基于TreeMap來實現(xiàn)。

TreeMap底層則基于紅黑樹來實現(xiàn)，可以保證元素沒有重復，同時還能按照我們自己定義的排序規(guī)則在你每次插入一個元素的時候來進行自定義的排序。

所以這里我們的排序規(guī)則：就是按照契約的最近一次續(xù)約時間來排序。

其實這個優(yōu)化就是如此的簡單，就是維護這么一個排序數(shù)據(jù)結構而已。

我們現(xiàn)在來看一下Hadoop中的契約監(jiān)控的源碼實現(xiàn)：

每次檢查契約是否過期的時候，你不要遍歷成千上萬的契約，那樣遍歷效率當然會很低下。

我們完全可以就從TreeSet中獲取續(xù)約時間最老的那個契約，假如說連最近一次續(xù)約時間最老的那個契約都還沒過期，那么就不用繼續(xù)檢查了?。∵@說明續(xù)約時間更近的那些契約絕對不會過期！

舉個例子：續(xù)約時間最老的那個契約，最近一次續(xù)約的時間是10分鐘以前，但是我們判斷契約過期的限制是超過15分鐘不續(xù)約就過期那個契約。

這個時候，連10分鐘以前續(xù)約的契約都沒有過期，那么那些8分鐘以前，5分鐘以前續(xù)約的契約，肯定也不會過期?。?/p>

這個機制的優(yōu)化對性能的提升是相當有幫助的，因為正常來說，過期的契約肯定還是占少數(shù)，所以壓根兒不用每次都遍歷所有的契約來檢查是否過期。

我們只需要檢查續(xù)約時間最舊的那幾個契約就可以了，如果一個契約過期了，那么就刪掉那個契約，然后再檢查第二舊的契約好了。以此類推。

通過這個TreeSet排序 + 優(yōu)先檢查最舊契約的機制，有效的將大規(guī)模集群下的契約監(jiān)控機制的性能提升至少10倍以上，這種思想是非常值得我們學習和借鑒的。

給大家稍微引申一下，在Spring Cloud微服務架構中，Eureka作為注冊中心其實也有續(xù)約檢查的機制，跟Hadoop是類似的。

如果想了解Eureka注冊中心相關技術的朋友，建議看一下：用SpringCloud的時候胡亂寫配置的兄弟們，事故加班一定很多

但是在Eureka中就沒有實現(xiàn)類似的續(xù)約優(yōu)化機制，而是暴力的每一輪都遍歷所有的服務實例的續(xù)約時間。

如果你面對的是一個大規(guī)模部署的微服務系統(tǒng)呢，情況就不妙了！

部署了幾十萬臺機器的大規(guī)模系統(tǒng)，有幾十萬個服務實例的續(xù)約信息駐留在Eureka的內(nèi)存中，難道每隔幾秒鐘都要遍歷幾十萬個服務實例的續(xù)約信息嗎？

最后給大家提一句，優(yōu)秀的開源項目，蘊含著很多優(yōu)秀的設計思想。多看各種優(yōu)秀開源項目的源碼，是短時間內(nèi)快速、大幅度提升一個人的技術功底和技術水平的方式，大家不妨嘗試一下。