本文轉(zhuǎn)載自微信公眾號「KK架構師」，作者wangkai。轉(zhuǎn)載本文請聯(lián)系KK架構師公眾號。

專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)綏濱免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

一、分布式系統(tǒng)中的心跳技術

心跳是分布式技術中常用的技術手段。心跳，顧名思義，就是以固定的頻率向其他節(jié)點匯報當前節(jié)點狀態(tài)的方式。收到心跳，一般可以認為發(fā)送心跳的這個節(jié)點在當前的網(wǎng)絡拓撲中是良好的。

當然，心跳匯報時，一般也會攜帶一些附加的狀態(tài)、元數(shù)據(jù)信息、當前節(jié)點的信息，以便其他節(jié)點管理。

心跳有兩種方式：

• 單向的 heartbeat;
• 交互的 ping-pong;

第一種方式下，target 進程需要定時給 detector 發(fā)送消息，告知自己的存活性。而 detector 無需給 target 回復任何消息，只是每隔一段時間去檢測 target 進程有沒有匯報。

第二種方式更為常見，比如我們的 redis 就是采用這種方式：

 
 
 
 

  
  
  
  
detector -> target: Are you ok? 
  
  
  
  
target -> detector: Yeah, pretty good. 
 
 
 
 

Detector 發(fā)起檢測，如果 target 連續(xù) N 次不回復消息，那么 detector 就認為其處于 non-active 狀態(tài)。

那么常用的心跳檢測機制有哪些：

(1)傳統(tǒng)的周期檢測心跳機制

其檢測方法很粗暴：設定一個超時時間 T，只要在 T 之內(nèi)沒有收到對方的心跳包便可認為對方宕機，方法簡單有效，使用比較廣泛。

所以這個方法的重點就在于這個超時時間 T 的設置，設置的太短了，有可能會因為當前網(wǎng)絡阻塞導致誤判，讓這個節(jié)點下線，產(chǎn)生其他不必要的后果;設置的太長，會導致判斷“遲緩”，所以需要綜合各種情況來權衡和設定。

HDFS 就是使用的這種心跳機制。

(2)累積失效檢測機制

隨著網(wǎng)路負載的加大，Server 心跳的接收時間可能會大于上限值 T;但當網(wǎng)絡壓力減少時，心跳接收時間又會小于 T ，如果用一成不變的T 來反映心跳狀況，則會造成判斷”遲緩“或誤判。這個時候我們可以計算心跳延遲的概率，用這個概率來判斷是否發(fā)生故障，提高準確性。

二、DataNode 是如何向 NameNode 發(fā)送心跳的

我們從 hadoop 源碼看 DataNode 是如何發(fā)送心跳的

1、從 DataNode 類的 main 方法開始

2、創(chuàng)建 DataNode

3、實例化 DataNode

4、創(chuàng)建實例

5、 new 了 DataNode

6、 這個方法構造函數(shù)有點長，拉到最下面

7、然后來到這個方法里

這個方法表面看起來是刷新 NameNode，實際上里面做了兩件事情，把自己注冊到 NameNode 上，另外一件事情是向 NameNode 定時發(fā)送心跳。

8、點進去，現(xiàn)在是在 BlockPoolManager 里面

9、再來到這個方法里

10、發(fā)現(xiàn)它在遍歷這個 BPOfferService

這里大致說明一下 offerServices 是個什么數(shù)據(jù)結構。

用一張圖來表示吧

那個 offerServices 其實裝的就是最左邊的 BPOfferService。

每個 BPOfferService 里面有兩個 BpServiceActor，每個 BpServiceActor 對應一個 NameNode。

如果是上圖中的高可用，那么一主一備兩個 NameNode，分別對應一個 BpServiceActor。

所以遍歷 offerService 其實就是在遍歷整個集群每個聯(lián)邦的每個 NameNode 節(jié)點。

11、開始遍歷(當前類：BpOfferService)

12、線程 start(當前類：BPServiceActor)

再點進去已經(jīng)是 Thread 的方法了，可見它其實是個線程。

那我們應該看這個類的 run 方法。

13、線程的運行內(nèi)容

run 方法的上半部分是往 NameNode 注冊，下半部分是發(fā)送心跳

14、發(fā)送心跳

可以看到這是一個 while 循環(huán)，每隔一段時間(dnConf.heartBeatInterval = 3秒)就會執(zhí)行一次

可以看到 DataNode 的心跳就是采用了周期性檢測機制，每隔 3 s ，往所有的 NameNode 發(fā)送心跳。

15、再點進去，已經(jīng)是 NameNode 的 proxy 代理方法了。

因為它是靠 rpc 通信的，此時 DataNode 是客戶端，NameNode 是服務端。

這個時候，我們應該看 NameNodeRpcServer 方法，具體的實現(xiàn)是在這個方法里的。

16、看服務端的處理，此時我們在 NameNodeRpcServer 類中

這個方法里的具體就不看了，(其實也很重要的的)。

大致就是把 DataNode 心跳包的基本信息(比如本節(jié)點的存儲容量信息等)更新到 NameNode 對應的結構中。

并且更新上一次心跳時間，以便下次判斷 DataNode 是否心跳超時。

其實心跳就是這么樸素了。

最后，NameNode 會在心跳的響應中，告訴 DataNode 應該做些什么事情，比如把本節(jié)點的 Block 備份到其他節(jié)點上去。

也就是說，NameNode 本身不會和 DataNode 通信，而是在心跳信息中告訴 DataNode 該做什么。

三、小結

本次通過瀏覽 DataNode 代碼了，知道了其實 DataNode 的心跳，就是DataNode 在后臺啟動了線程，定時向整個集群所有的 NameNode 發(fā)送心跳信息，NameNode 會在心跳響應信息中告訴 DataNode 本次該做些什么事情。

本文題目：談一談DataNode如何向NameNode發(fā)送心跳的
新聞來源：http://fisionsoft.com.cn/article/cooiphi.html