如何解決HBase在數據大量寫入時導致RegionServer崩潰問題

這篇文章主要講解了“如何解決HBase在數據大量寫入時導致RegionServer崩潰問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何解決HBase在數據大量寫入時導致RegionServer崩潰問題”吧！

日志報錯信息如下：

warn：hdfs.DFSClient:DFSOutputStream ResponseProcessor exception for block blk_xxxx java.net.SocketTimeoutException: 66000 millis timeout while waiting for channel to be ready for read. ch: java.nio.channels.SocketChannel

實際上，這個問題并不是由Replication功能引起的，而由客戶端在數據密集寫入時超時引起的

============================以下內容來源于網絡===================================

正常情況下DFSClient寫block數據的過程是：

1. DFSClient端 
   a）DFSOutputStream負責數據的接收和寫入，即通過DFSOutputSummer中的write方法（synchronized）獲得數據，而sync（主要代碼 synchronized(this)）通過FlushBuffer建立packet后，通過enqueuePacket向dataQueue中寫入數據。 
   b）DFSOutputStream中的DataStreamer（Daemon線程），負責向DataNode發送數據，每次發送前會檢查dataQueue中是否有數據，沒有就等待。 
   c）DataStreamer建立pipeline傳輸數據時，對這個pipeline會起一個ResponseProcessor（Thread）去獲得DataNode的反饋ack，并判斷是否有錯誤、進行recoverBlock等 
2. DataNode端 
   a）在每個packet傳輸過程中，根據建立數據傳輸的pipleLine，上游依次向下游發送數據，下游依次向上游發送ack。 
   b）pipeline的最后一個節點（numTarget=0），PacketResponder 會一直運行lastDatanodeRun?方法，這個方法會在ack發送完畢(ackQueue.size()=0)后約1/2個dfs.socket.timeout?時刻發送心跳包，沿著pipeline發送給client。 
3. HBase端 
  HBase端通過hlog中的writer向hdfs寫數據，每次有數據寫入，都會sync。同時，HLog中有個logSyncer，默認配置是每秒鐘調用一次sync，不管有沒有數據寫入。 


這個問題首先是由于超時引起的，我們先分析一下超時前后DFSClient和DataNode上發生了什么。 
1. 問題重現 
    a）客戶端ResponseProcessor報69秒socket超時，出錯點在PipelineAck.readFields()。出錯后直接catch，標記hasError=true，closed=true。這個線程不會停止。 
    b）DataStreamer在輪詢中調用processDatanodeError對hasError=true進行處理。此時errorIndex=0（默認值），首先會拋出Recovery for Block的異常. 然后關閉blockstream，重新基于兩個節點的pipeline進行recoverBlock。 
    c）在DataNode上，processDatanodeError()關閉blockstream。這將導致pipeline中的packetResponder被interrupted和terminated。 
    d）在DataNode上，processDatanodeError()關閉blockstream，導致BlockReceiver的readNextPacket()中的readToBuf讀取不到數據，throw EOFException的異常。這個異常一直向上拋，直到DataXceiver的run中，它將導致DataXceiver中止運行，提示DataNode.dnRegistration Error。 
   e）recoverBlock會正常進行，并先在兩個節點上完成（第二個和第三個）。隨后Namenode會發現replicas數量不足，向DataNode發起transfer block的命令，這是一個異步的過程。但是在hlog檢查時，transfer很有可能未完成，這時會報 pipeline error detected. Found 2 replicas but expecting 3 replicas。并關閉hlog。


以上就是根據日志可以看到的錯誤過程。 
2. 問題分析 
a)為什么會超時，為什么心跳包沒有發？ 
根據以上的分析，ResponseProcessor socket 69秒超時是導致后續一系列異常和hlog關閉的原因。那么為何會發生socket超時？ResponseProcessor應該會在dfs.socket.timeout的1/2時間內收到HeartBeat包。 
經過打印日志，我們發現，DataNode上配置的dfs.socket.timeout為180秒，而HBase調用DFSClient時采用默認配置，即60秒。因此，DFSClient認為超時時間為3×nodes.length+60=69秒，而DataNode端發送心跳包的timeout=1/2×180=90秒！因此，如果在沒有數據寫入的情況下，DataNode將在90秒后發送心跳包，此時DFSClient已經socketTimeout了，并導致后續的一系列現象。 
b）為什么會在69秒內沒有新的packet發送過去呢？ 
我們先分析一下DFSOutputStream寫數據和sync的同步關系。DFSOutputStream繼承自FSOutputSummer，DFSOutputStream接收數據是通過FSOutputSummer的write方法，這個方法是synchronized。而sync方法的flushBuffer()和enqueuePacket()，也在synchronized(this)代碼塊中。也就是說，對一個DFSOutputStream線程，如果sync和write同時調用，將發生同步等待。在HBase的場景下，sync發生的頻率非常高，sync搶到鎖的可能性很大。這樣，就很有可能在不斷的sync，不斷的flushBuffer，但是卻沒能通過write寫入數據（被blocked了）。這就是導致超時時間內一直沒有packet發送的原因。 

綜上，HBase業務調用的特點和DFSOutputStream的synchronized代碼塊，很有可能69秒中沒有packet寫入。但這個時候，不應該socket超時，socket超時是這個問題的根本原因，而socket超時的原因是配置不一致。 


3. 問題解決 

在hdfs端和HBase端，給dfs.socket.timeout設置一個較大的值，比如300000（300秒）【注意兩處設置的值要相等】

感謝各位的閱讀，以上就是“如何解決HBase在數據大量寫入時導致RegionServer崩潰問題”的內容了，經過本文的學習后，相信大家對如何解決HBase在數據大量寫入時導致RegionServer崩潰問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！