分布式系統的節點之間常采用心跳來維護節點的健康狀態，如yarn的rm與nm之間，hdfs的nn與dn之間。
DataNode會定期（dfs.heartbeat.interval配置項配置，默認是3秒）向namenode發送心跳，
如果Namenode長時間沒有接受到datanode發送的心跳，我們在50070的nn管理界面上就會看到它的lastcontact
字段越來越大，至到最后變為dead,namenode就會認為該DataNode失效。
ClientProtocol.sendHeartBeat方法就是用於心跳匯報的接口，除了攜帶標識DataNode身份的DataNodeRegistration
對象外，還包含數據節點上所有存儲的狀態，緩存的狀態，正在寫文件數據的連接數，讀寫數據使用的線程數等。
sendHeartBeat會返回一個heartBeatResponse對象，這個對象包含了Namenode向DataNode發送的名字節點指令，以及當前NameNode
的HA狀態，即它是Active的還是standBy的，需要特別注意的是，在開啟了HA的HDFS集群中，DataNode是需要同時向ACTIVE和standby的
NN發送心跳的，不過只有Active的NN才能向DN下發名字節點指令。
DataNode的啟動過程
DataNode進程啟動后與NN的交互包含三個部分，握手，注冊與塊匯報與緩存匯報。
DN啟動時會首先通過datanodeProtocol.versionRequest獲取NN的版本號以及存儲信息等，然后DN會對NN的當前軟件版本號和DN的當前軟件版本號進行
比較，確保他們是一致的。當軟件升級和NN格式化之后，這種比對一般是通不過的。
成功完成握手后，DN會通過DatanodeProtocol.register方法向NN注冊，NN接收到注冊請求后，會判斷當前DN的配置是否屬於集群，NN有白名單或黑名單與安全
配置，再確認他們之間的版本號是否一致。
注冊成功后，DN就需要將本地的數據塊以及緩存的數據塊向上報到到NN，NN會利用這些信息重新建立內存中數據塊與DN之間的對應關系。
DN啟動成功后，通過心跳與NN交互,NN知道DN的活動狀態以給其派發任務。NN會在DN的心跳信息中攜帶名字節點指令，指導DN進行數據塊的復制，刪除與恢復等操作。
當DN成功地添加了一個新的數據塊或刪除一個已有的數據塊時，需要通過DatanodeProtocol.blockReeivedAndDeleted方法向NN匯報，NN接收到匯報之后，
會更新NN內存中數據塊與數據節點之間的對應關系。
運維中遇到一個問題，版本CDH4，HA切換比較頻繁，而且ZK檢查到ACTIVE NN沒有響應后，完成切換，但成為ACTIVE的NN又沒有響應，又切換。
同時伴隨的一個問題時，有部分DN節點啟動后心跳信息一直收不到，LASTCONCAT一直變大，最后變為dead,經過查看DN的日志信息，發現
DN在scandatapool的時候卡在那里，根據我們上面的理解，是它在啟動后掃描本地的數據塊的時候時間過長，可能是因為內存不足，因為數據塊掃描需要遞歸進行，
需要建立一個大的存儲，然后調整Xmx內存為原來的兩倍后問題解決。同時HA的頻繁節換的問題也消失。
這個問題的原因是因為在一開始DN的機器維護的數據塊少，消耗的內存不多，隨着數據塊的增多，DN需要的內存也在增加，如果內存給不到位，就容易卡死。
同樣類似的問題，我們之前維護的時候發現NN切換並且NN啟動的過程卡死，最后發現原因都是因為內存問題，不過NN是因為小文件過多，一億多的inodes,造成加載過程過慢。
而且原來給的內存不夠所致。這一點情況在維護的過程中一定要特別注意。