IT技術互動交流平臺

HBase的Write Ahead Log (WAL) 整體架構 線程模型

作者:Yijian  來源:IT165收集  發布日期:2016-08-26 20:21:17

解決的問題

HBase的Write Ahead Log (WAL)提供了一種高并發、持久化的日志保存與回放機制。每一個業務數據的寫入操作(PUT / DELETE)執行前,都會記賬在WAL中。

如果出現HBase服務器宕機,則可以從WAL中回放執行之前沒有完成的操作。

本文主要探討HBase的WAL機制,如何從線程模型、消息機制的層面上,解決這些問題:

1. 由于多個HBase客戶端可以對某一臺HBase Region Server發起并發的業務數據寫入請求,因此WAL也要支持并發的多線程日志寫入。——確保日志寫入的線程安全、高并發。

2. 對于單個HBase客戶端,它在WAL中的日志順序,應該與這個客戶端發起的業務數據寫入請求的順序一致。

(對于以上兩點要求,大家很容易想到,用一個隊列就搞定了。見下文的架構圖。)

3. 為了保證高可靠,日志不僅要寫入文件系統的內存緩存,而且應該盡快、強制刷到磁盤上(即WAL的Sync操作)。但是Sync太頻繁,性能會變差。所以:

 (1) Sync應當在多個后臺線程中異步執行

 (2) 頻繁的多個Sync,可以合并為一次Sync——適當放松對可靠性的要求,提高性能。

架構圖——線程模型、消息機制

下面是我畫的HBase WAL架構圖。我在圖上加了不少注解,所以這張圖應該是自解釋的:

 Region Server RPC服務線程

這些線程處理HBase客戶端通過RPC服務調用(實際上是Google Protobuf服務調用)發出的業務數據寫入請求。在上圖的例子中,“Region Server RPC服務線程1” 做了3個Row的Append操作,和一個強制刷磁盤的Sync操作。

Sync操作是為了確保之前的Append操作(包括涉及的業務數據)一定可靠地記錄到了磁盤上的日志中,然后HBase才能做后續相對不可靠的復雜操作,比如寫入MemStore。——這就是Write Ahead的語義。

從架構圖中可見,并發的Append操作只是往隊列中增加了Append請求對象。

這里的隊列是一個LMAX Disrutpor RingBuffer(我的這篇文章作了介紹),你可以簡單理解為是一個無鎖高并發隊列。

Append的具體代碼如下:

對于Sync操作:

(1)往隊列里放一個SyncFuture對象,代表一次Sync操作請求。

每一個SyncFuture都有一個自增的Sequence ID——這是全局唯一的,由LMAX Disrutpor隊列創建。后來的SyncFuture的Sequence ID更高。

(2)調用SyncFuture.get()阻塞等待,直到后臺線程(架構圖中的SyncRunner)通知SyncFuture退出阻塞,表明WAL日志已經保存在了磁盤上。

WAL日志消費線程

WAL機制中,只有一個WAL日志消費線程,從隊列中獲取Append和Sync操作。這樣一個多生產者,單消費者的模式,決定了WAL日志并發寫入時日志的全局唯一順序。

1. 對于獲取到的Append操作,直接調用Hadoop Sequence File Writer將這個Append操作(包括元數據和row key, family, qualifier, timestamp, value等業務數據)寫入文件。

    因此WAL日志文件使用的是Hadoop Sequence文件格式。當然,它也可以替換成其他存儲格式,如Avro。

    Hadoop Sequence文件格式不再這里累述,其主要特點是:

   (1) 二進制格式。row key, family, qualifier, timestamp, value等HBase byte[]數據,都原封不動地順序寫入文件。

   (2) Sequence文件中,每隔若干行,會插入一個16字節的魔數作為分隔符。這樣如果文件損壞,導致某一行殘缺不全,可以通過這個魔數分隔符跳過這一行,繼續讀取下一個完整的行。

   (3) 支持壓縮。可以按行壓縮。也可以按塊壓縮(將多行打成一個塊)

2. 對于獲取到的Sync操作,會提交給后臺SyncRunner的線程池(見上文架構圖)異步執行。

以上的this.syncRunners就是SyncRunner線程池。可以看到,通過計算syncRunnerIndex,采用了簡單的輪循提交算法。

另外,WAL日志消費線程,會嘗試收集一批SyncFuture對象(即sync操作),一次提交給SyncRunner。

        所以,在以上代碼中,可以看到傳入offer()方法的,是this.syncFutures這一SyncFutures[]數組,而不是單個SyncFuture對象。

        收集一批次再提交,性能比較好。但是單個批次需要積攢的SyncFuture對象越多,則Sync的及時性越差,會導致前臺Region Server RPC服務線程阻塞在SyncFuture.get()上的時間就越長。

        因此,這里存在吞吐量和及時性之間的平衡。HBase為了支持海量數據的寫入,在這里更傾向于高吞吐量,體現在了以下注釋中。具體多少個SyncFuture構成一個批次,有一定的策略,在此不再累述。

SyncRunner線程

1. 從隊列中獲取一個由WAL日志消費線程提交的SyncFuture(下圖紅框中的代碼)。

2. 調用文件系統API,執行sync()操作(下圖藍框中的代碼)

合并多次頻繁的sync()操作,提高性能。

        上文提到,WAL日志消費線程一次會提交多個SyncFuture。對此,SyncRunner線程只會落實執行其中最新的SyncFuture(也就是Sequence ID最大的那個)所代表的Sync操作。而忽略之前的SyncFuture。

        這就是下圖綠框中的代碼。

3. 如果sync()完成,或者因為上面提到的合并忽略了某一個SyncFuture,那么會調用releaseSyncFuture() ==> Object.notify()來通知SyncFuture阻塞退出。

   之前阻塞在SyncFuture.get()上的Region Server RPC服務線程就可以繼續往下執行了。

至此,整個WAL寫入流程完成。

總結

我覺得對線程并發寫入文件時,用隊列來協調,保證日志寫入的順序,這還是比較容易想到的。

但是,提供Sync() API確保日志寫入的可靠性,同時避免頻繁的Sync()操作影響性能。——這是HBase WAL實現的一大亮點。

后續我再研究研究WAL的checkpoint和讀取WAL回放機制,再和大家分享。

Tag標簽: 線程   架構   模型  
  • 專題推薦

About IT165 - 廣告服務 - 隱私聲明 - 版權申明 - 免責條款 - 網站地圖 - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循相關法律法規
香港最快开奖现场直播结果