HBase中Replication的用法詳解

這篇文章主要介紹“HBase中Replication的用法詳解”，在日常操作中，相信很多人在HBase中Replication的用法詳解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”HBase中Replication的用法詳解”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

Replication：復(fù)制，指的是持續(xù)的將同一份數(shù)據(jù)拷貝到多個地方進行存儲，是各種存儲系統(tǒng)中常見而又重要的一個概念，可以指數(shù)據(jù)庫中主庫和從庫的復(fù)制，也可以指分布式集群中多個集群之間的復(fù)制，還可以指分布式系統(tǒng)中多個副本之間的復(fù)制。它的難點在于數(shù)據(jù)通常是不斷變化的，需要持續(xù)的將變化也反映到多個數(shù)據(jù)拷貝上，并保證這些拷貝是完全一致的。

通常來說，數(shù)據(jù)復(fù)制到多個拷貝上有如下好處：

• 多個備份提高了數(shù)據(jù)的可靠性

• 通過主從數(shù)據(jù)庫/主備集群之間的復(fù)制，來分離OLTP和OLAP請求

• 提高可用性，即使在單副本掛掉的情況下，依然可以有其他副本來提供讀寫服務(wù)

• 可擴展，通過增加副本來服務(wù)更多的讀寫請求

• 跨地域數(shù)據(jù)中心之間的復(fù)制，Client通過讀寫最近的數(shù)據(jù)中心來降低請求延遲

HBase中的Replication指的是主備集群間的復(fù)制，用于將主集群的寫入記錄復(fù)制到備集群。HBase目前共支持3種Replication，分別是異步Replication、串行Replication和同步Replication。

如果想把HBase的Replication搞清楚，首先需要了解下HBase的架構(gòu)。

HBase集群是由一組進程組成的，進程按角色分為Master和RegionServer，其中Master負責DDL操作，比如建表、刪表，而RegionServer負責DML操作，比如數(shù)據(jù)的讀寫操作等。從數(shù)據(jù)視圖上講，HBase中的Table會按Range切分為多個Region，然后由不同的RegionServer來負責對外提供服務(wù)。

RegionServer的內(nèi)部則主要有BlockCache，MemStore和WAL等幾部分組成，需要注意的是每個Region的每個Column Family有自己獨享的MemStore，但是BlockCache和WAL則是多個Region共享的。WAL(Write-ahead logging)是數(shù)據(jù)庫中的常用技術(shù)，所有的修改在寫入數(shù)據(jù)庫之前都需要持久化到WAL中，從而確保了在出現(xiàn)故障的時候，可以從WAL中回放出已經(jīng)成功寫入的數(shù)據(jù)。

HBase中的Replication也是基于WAL的，其在主集群的每個RegionServer進程內(nèi)部起了一個叫做ReplicationSource的線程來負責Replication，同時在備集群的每個RegionServer內(nèi)部起了一個ReplicationSink的線程來負責接收Replication數(shù)據(jù)。ReplicationSource記錄需要同步的WAL隊列，然后不斷讀取WAL中的內(nèi)容，同時可以根據(jù)Replication的配置做一些過濾，比如是否要復(fù)制這個表的數(shù)據(jù)等，然后通過replicateWALEntry這個Rpc調(diào)用來發(fā)送給備集群的RegionServer，備集群的ReplicationSink線程則負責將收到的數(shù)據(jù)轉(zhuǎn)換為put/delete操作，以batch的形式寫入到備集群中。

因為是后臺線程異步的讀取WAL并復(fù)制到備集群，所以這種Replication方式叫做異步Replication，正常情況下備集群收到最新寫入數(shù)據(jù)的延遲在秒級別。

串行Replication指的是：對于某個Region來說，嚴格按照主集群的寫入順序復(fù)制到備集群，其是一種特殊的Replication。同時默認的異步Replication不是串行的，主要原因是Region是可以移動的，比如HBase在進行負載均衡時移動Region。假設(shè)RegionA首先在RegionServer1上，然后其被移動到了RegionServer2上，由于異步Replication是存在延遲的，所以RegionA的最后一部分寫入記錄還沒有完全復(fù)制到備集群上。在Region移動到RegionServer2之后，其開始接收新的寫入請求，并由RegionServer2來復(fù)制到備集群，所以在這個時候RegionServer1和RegionServer2會同時向備集群進行復(fù)制，而且寫入記錄復(fù)制到備集群的順序是不確定的。

如上圖所示這種極端情況下，還會導(dǎo)致主備集群數(shù)據(jù)的不一致。比如RegionServer1上最后一個未同步的寫入操作是Put，而RegionA被移動到RegionServer2上的第一個寫入操作是Delete，在主集群上其寫入順序是先Put后Delete，如果RegionServer2上的Delete操作先被復(fù)制到了備集群，然后備集群做了一次Major compaction，其會刪除掉這個Delete marker，然后Put操作才被同步到了備集群，因為Delete已經(jīng)被Major compact掉了，這個Put將永遠無法被刪除，所以備集群的數(shù)據(jù)將會比主集群多。

解決這個問題的關(guān)鍵在于需要確保RegionServer2上的新寫入操作必須在RegionServer1上的寫入操作復(fù)制完成之后再進行復(fù)制。所以串行Replication引入了一個叫做Barrier的概念，每當Region open的時候，就會寫入一個新的Barrier，其值是Region open時讀到的最大SequenceId加1。SequenceId是HBase中的一個重要概念，每個Region都有一個SequenceId，其隨著數(shù)據(jù)寫入嚴格遞增，同時SequenceId會隨著每次寫入操作一起寫入到WAL中。所以當Region移動的時候，Region會在新的RegionServer重新打開，這時就會寫入一個新的Barrier，Region被移動多次之后，就會寫入多個Barrier，來將Region的寫入操作劃分成為多個區(qū)間。同時每個Region都維護了一個lastPushedSequenceId，其代表這個Region當前推送成功的最后一個寫操作的SequenceId，這樣就可以根據(jù)Barrier列表和lastPushedSequenceId來判斷WAL中的一個寫入操作是否能夠復(fù)制到備集群了。

以上圖為例，Pending的寫入記錄就需要等待lastPushedSequenceId推到Barrier2之后才能開始復(fù)制。由于每個區(qū)間之間只會有一個RegionServer來負責復(fù)制，所以只有和lastPushedSequenceId在同一個區(qū)間內(nèi)的RegionServer才能進行復(fù)制，并在復(fù)制成功后不斷更新lastPushedSequenceId，而在lastPushedSequenceId之后各個區(qū)間的RegionServer則需要等待lastPushedSequenceId被推到自己區(qū)間的起始Barrier，然后才能開始復(fù)制，從而確保了Region的寫入操作可以嚴格按照主集群的寫入順序串行的復(fù)制到備集群。

同步Replication是和異步Replication對稱的概念，其指的是主集群的寫入操作必須被同步的寫入到備集群中。異步Replication的最大問題在于復(fù)制是存在延遲的，所以在主集群整集群掛掉的情況下，備集群是沒有已經(jīng)寫入的完整數(shù)據(jù)的，對于一致性要求較高的業(yè)務(wù)來說，是不能把讀寫完全切到備集群的，因為在這個時候可能存在部分最近寫入的數(shù)據(jù)無法從備集群讀到。所以同步Replication的核心思路就是在寫入主集群WAL的同時，在備集群上寫入一份RemoteWAL，只有同時在主集群的WAL和備集群的RemoteWAL寫入成功了，才會返回給Client說寫入成功。這樣當主集群掛掉的時候，便可以在備集群上根據(jù)Remote WAL來回放出來主集群上所有寫入記錄，從而確保備集群和主集群數(shù)據(jù)的一致。

需要注意的是，同步Replication是在異步Replication的基礎(chǔ)之上的，也就是說異步Replication的復(fù)制鏈路還會繼續(xù)保留，同時增加了新的寫Remote WAL的步驟。對于具體的實現(xiàn)細節(jié)來說，首先是增加了一個Sync replication state的概念，其總共有三個狀態(tài), 分別是Active，Downgrade Active和Standby。這幾個狀態(tài)的轉(zhuǎn)換關(guān)系如下圖所示，Standby在提主的時候需要首先提升為Downgrade Active，然后才能提升為Active。但是Active是可以直接降級為Standby的。目前這個狀態(tài)是保存在ReplicationPeerConfig中的, 其表示一個集群在這個ReplicationPeer中處于哪個狀態(tài)。

然后實現(xiàn)了一個DualAsyncFSWAL來同時寫主集群的WAL和備份集群的Remote WAL。寫WAL的操作是對于HDFS的rpc請求，其會有三種結(jié)果： 成功，失敗或者超時。當超時的時候，對于HBase來說結(jié)果是不確定的，即數(shù)據(jù)有可能成功寫入到WAL或Remote WAL里了，也有可能沒有。只有同時寫成功或者同時寫失敗的時候，主集群和備集群才會有一樣的WAL，如果是主集群寫WAL成功，寫Remote WAL失敗或者超時，這時候主集群WAL里的數(shù)據(jù)就有可能比備集群的Remote WAL多。相反如果寫備集群Remote WAL成功了，而主集群的WAL寫失敗或者超時了，備集群的Remote WAL里的數(shù)據(jù)就有可能比主集群多。當兩邊都超時的時候, 就不確定那邊多了。所以同步復(fù)制的關(guān)鍵就在于在上述情況下，如何確保主備集群數(shù)據(jù)的最終一致。即在切換主備集群的時候，Client應(yīng)該始終從主備集群看到一致的數(shù)據(jù)。而且在主備沒有達到一致的中間狀態(tài)時，需要一些限制來確保Client沒法讀到這種中間不一致的結(jié)果。所以總結(jié)一下就是主備集群最終一致，但對于Client來說是強一致，即成功寫入的數(shù)據(jù)無論主備集群都要一定能讀到。具體的實現(xiàn)細節(jié)可以參考HBaseCon Asia 2018：HBase at Xiaomi[1]。

對比異步復(fù)制來看，同步復(fù)制主要是影響的寫路徑，從我們的測試結(jié)果上來看，大概會有14%的性能下降，后續(xù)計劃在HBASE-20422[2]中進行優(yōu)化。

除了上述3種Replication之外，HBase還支持插件式的Replication Endpoint，可以自定義Replication Endpoint來實現(xiàn)各種各樣的功能。具體到小米來說，我們實現(xiàn)了可以在不同表之間的Replication Endpoint，比如可以將主集群的表A復(fù)制到備集群的表B，其應(yīng)用場景有集群遷移，Namespace更換或者表名更換等。同時為了實現(xiàn)Point-in-time Recovery，我們做了可以同步數(shù)據(jù)到小米消息隊列Talos的Replication Endpoint，當出現(xiàn)需要恢復(fù)某個時間點t1的場景時，可以首先找到冷備中距離t1最近的一個的Snapshot進行恢復(fù)，然后將消息隊列中的數(shù)據(jù)來回放到t1時間點，從而做到Point-in-time Recovery。

到此，關(guān)于“HBase中Replication的用法詳解”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>