JDHBase在京東集團作為線上kv存儲，承擔了大量在線業(yè)務(wù)，11.11、6.18 均經(jīng)歷了每天萬億級讀寫訪問請求，目前規(guī)模達到7000+節(jié)點，存儲容量達到了90PB。場景涉及商品訂單、評價、用戶畫像、個性推薦、金融風控、物流、監(jiān)控等700+業(yè)務(wù)。

?

?

JDHBase上承載了大量核心業(yè)務(wù)，遍布全球多個Data Center。為了保障業(yè)務(wù)穩(wěn)定不間斷運行，我們構(gòu)建了JDHBase集群的異地多活系統(tǒng)。主要介紹在我們在異地多活系統(tǒng)的實踐。

?

?

HBase Replication原理

?

HBase是典型的LSM（Log-Structured Merge-Tree）結(jié)構(gòu)數(shù)據(jù)庫，服務(wù)端響應(yīng)客戶端寫請求過程中，會寫入Memstore（內(nèi)存）中和順序的寫入WAL日志（HDFS文件）中，WAL日志確保數(shù)據(jù)真正寫入磁盤，從而在節(jié)點故障時恢復未被持久化的內(nèi)存數(shù)據(jù)。

?

?

HBase的Replication是基于WAL日志文件的。在主集群中的每個RegionServer上，由ReplicationSource線程來負責推送數(shù)據(jù)，在備集群的RegionServer上由ReplicationSink線程負責接收數(shù)據(jù)。ReplicationSource不斷讀取WAL日志文件的數(shù)據(jù)，根據(jù)Replication的配置做一些過濾，然后通過replicateWALEntry的rpc調(diào)用來發(fā)送給備集群的RegionServer，備集群的ReplicationSink線程則負責將收到的數(shù)據(jù)轉(zhuǎn)換為put/delete操作，以batch的形式寫入到備集群中。

?

?

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

?

?

JDHBase異地多活架構(gòu)

?

JDHBase服務(wù)端與客戶端交互主要包含三個組件：Client、JDHBase集群、Fox Manager。

Client啟動時首先向Fox Manager端匯報用戶信息，Fox Manager進行用戶認證后，返回集群連接信息，Clinet收到集群連接信息后，創(chuàng)建集群連接HConnection，從而與Fox Manager指定的集群進行數(shù)據(jù)交互。

?

1、Fox Manager配置中心

負責維護用戶及JDHBase集群信息，為用戶提供配置服務(wù)，同時管理員做配置管理。

?

• Policy Server：分布式無狀態(tài)的服務(wù)節(jié)點，響應(yīng)外部請求。數(shù)據(jù)持久化目前為可選的Mysql或Zookeeper。Policy Server中還包含了一個可選的Rule Engine插件，用于根據(jù)規(guī)則和集群的狀態(tài)，自動修改用戶配置，如集群連接地址信息、客戶端參數(shù)等。

• Service Center：Admin配置中心的UI界面，供管理員使用。

• VIP Load Balance：對外將一組Policy Server提供統(tǒng)一訪問地址并提供負載均衡能力。

2、JDHBase Cluster

JDHBase Cluster提供高吞吐的在線OLTP能力。我們對可靠性要求比較高的業(yè)務(wù)做了異地多活備份。

?

?

• Active Cluster：正常情況下業(yè)務(wù)運行在此集群上。數(shù)據(jù)會異步備份到Standby Cluster，同時保證數(shù)據(jù)不丟失，但是會有延遲。

• Standby Cluster：異常情況下，全部或部分業(yè)務(wù)會切換到此集群運行。在此集群上運行的業(yè)務(wù)數(shù)據(jù)也會異步備份到Active Cluster上。

兩個集群間通過Replication備份數(shù)據(jù)，根據(jù)集群ID防止數(shù)據(jù)回環(huán)。主備集群間數(shù)據(jù)達到最終一致性。

實際生產(chǎn)中，我們根據(jù)兩個建群間的Replication，構(gòu)建了多集群間的Replication拓撲，使得集群互為主備。一個集群上會承載多個業(yè)務(wù)，不同的業(yè)務(wù)的備份也會散落在不同的集群上，形成多集群間的拓撲結(jié)構(gòu)。?

?

3、Client

?

?

Client負責拉取Fox Manager端配置信息，根據(jù)配置信息為用戶提供接口，與主集群或者備集群進行數(shù)據(jù)交互，同時將客戶端狀態(tài)上報給Fox Manager端。

?

?

集群切換

?

HBase在讀寫數(shù)據(jù)時，需要先經(jīng)過數(shù)據(jù)路由，找到數(shù)據(jù)所在（或應(yīng)當所在）的節(jié)點位置，然后與節(jié)點進行數(shù)據(jù)交互。簡單來說包含以下三步：

1、client端訪問HBase集群的zookeeper地址，通過訪問znode獲取集群META表所在位置。

2、訪問META表所在節(jié)點，查詢META表獲取數(shù)據(jù)分片（Region）信息。同時緩存META表數(shù)據(jù)。

3、根據(jù)數(shù)據(jù)分片信息訪問數(shù)據(jù)所在節(jié)點，進行數(shù)據(jù)交互。

?

?

JDHBase在client端數(shù)據(jù)路由前，多加了一步訪問Fox Manager的步驟，這一步驟主要有兩個作用：一是進行用戶認證；二是獲取用戶集群信息；三是獲取客戶端參數(shù)。

?

?

對集群切換來說，重要的是用戶集群信息和客戶端參數(shù)。Client端拿到具體的集群信息（zk地址），然后進行正常的數(shù)據(jù)路由，這樣業(yè)務(wù)的client端不需要關(guān)心訪問哪個集群，Fox Manager端只要保證為client提供的路由集群可用即可。

Fox Manager還會為Client提供一些特殊配置參數(shù)，例如重試、超時等，這些配置參數(shù)依據(jù)兩個維度：集群特性和業(yè)務(wù)屬性。這些參數(shù)的設(shè)置需要結(jié)合業(yè)務(wù)場景和要求長期觀察，屬于專家經(jīng)驗；也包括一些極端情況下的臨時參數(shù)。

我們也在client sdk中添加了metrics，用于評估client端視角的服務(wù)可用性。基于metrics，我們?yōu)橐恍O度敏感的業(yè)務(wù)開啟客戶端切換，當客戶端可用率降低生效。

在client sdk中添加的metrics，用于評估client端視角的服務(wù)可用性。Client啟動后會與Fox Manager建立心跳，一方面通過心跳上報客戶端狀態(tài)以及部分metrics指標到Fox Manager，這些數(shù)據(jù)能夠幫助我們分析服務(wù)運行狀態(tài)；另一方面Client端能夠獲取Fox Manager端對Client的配置更新。這樣，當管理員在Fox Manager為Client更新了集群配置，Client端能夠及時感知并重建數(shù)據(jù)路由。

另外，我們也做了對Client的精準控制。一方面可以使業(yè)務(wù)的部分Client實例路由到不同集群，另一方面可以作為一些極端情況下單個Client實例強制更新集群信息并切換的備用手段。

?

?

自動切換

?

在有了主備集群切換之后，我們?nèi)悦媾R時效性的問題。故障情況下，我們從監(jiān)控到異常到報警，到人工介入，最快仍需要分鐘級恢復服務(wù)可用性。這對一些線上業(yè)務(wù)來說仍然不可接受。

為了提高服務(wù)SLA質(zhì)量，我們開發(fā)了基于策略的主備集群自動切換。可以根據(jù)策略在服務(wù)異常時，觸發(fā)切換，將故障恢復時間控制到秒級。

?

?

首先我們在HMaster上做了狀態(tài)檢測插件，用于收集一些影響服務(wù)可用性的指標信息，heartbeat的方式上報到Fox Manager的PolicyServer中。

PolicyServer 是對外提供查詢和修改策略的服務(wù)，它所有策略數(shù)據(jù)會存儲在MySQL中。可以通過加節(jié)點的方式動態(tài)擴展形成一個服務(wù)集群，避免單點問題。

PolicyServer中的Rule Engine負責根據(jù)HMaster上報的集群狀態(tài)的指標信息推測執(zhí)行切換策略。服務(wù)可用性對不同指標的敏感度不同，本質(zhì)上Rule Engine在多個時間窗口上對不同的指標或多個指標的組合執(zhí)行策略。

Rule Engine不需要高吞吐，重要的是保障可用性，因此基于Raft做了高可用。Active的Rule Engine節(jié)點掛掉后，立即會被另外一臺節(jié)點接管。

?

動態(tài)參數(shù)&自動調(diào)速

?

Replication本身是通過RegionServer發(fā)送到備機群，而RegionServer本身有大量線程用于客戶端請求，Replication Source的線程和負載很難與客戶端請求相匹配，在大量寫或者有熱點的情況下，很容易出現(xiàn)Replication積壓。

這個問題我們可以通過調(diào)節(jié)Replication 參數(shù)來緩解這種積壓的情況。HBase本身基于觀察者模式支持動態(tài)參數(shù)，更新RegionServer節(jié)點參數(shù)后，執(zhí)行update config動作即可生效。我們擴展了動態(tài)參數(shù)，將Replication的一些參數(shù)做成了動態(tài)生效的。當Replication積壓比較嚴重時，可以在集群上或者在響應(yīng)的分組、節(jié)點調(diào)整參數(shù)，不需要重啟節(jié)點。

雖然Replication動態(tài)參數(shù)不需要重啟RegionServer，但是上線還是比較麻煩的，需要人工參與，并且寫熱點積壓不可預(yù)測，依然很難做到Replication平穩(wěn)順滑。因此我們進一步在Replication Source端根據(jù)當前節(jié)點積壓的情況（幾個閾值），在一定范圍內(nèi)自動調(diào)節(jié)Replication參數(shù)，從而達到自動調(diào)速的功能。目前參數(shù)自動調(diào)節(jié)范圍在基礎(chǔ)參數(shù)值的1-2倍之間。

跨機房異地數(shù)據(jù)中心的之間的帶寬是有限的，在業(yè)務(wù)流量高峰期不能將有限的網(wǎng)絡(luò)資源用于同步數(shù)據(jù)。因此在Fox Manager端我們也做了對集群的相應(yīng)控制，分時段調(diào)整Replication速度。

?

串行Repication

?

主備集群間的Replication本身是異步的，正常情況下兩個集群可以達到最終一致性。但是某些情況下并不能完全保證。

在HBase的Replication中，通過讀取每個RegionServer中的WAL將數(shù)據(jù)變化推到備集群。HBase在zookeeper中維護了一個對WAL文件的隊列，因此可以按創(chuàng)建時間順序讀取這些WAL文件。但是當Region發(fā)生移動或者RegionServer故障轉(zhuǎn)移，那么Region所在的新的RegionServer上的WAL日志可能會先于老的WAL日志推送到備集群，這種情況下備集群上的數(shù)據(jù)寫入順序與主集群是不一致的。更極端的情況，如果這種順序不一致發(fā)生在同一條數(shù)據(jù)上，那么可能會導致數(shù)據(jù)永久不一致。

舉個例子，首先在主集群中執(zhí)行Put，然后執(zhí)行Delete來刪除它，但是Delete操作先replication到了備集群，而備集群如果在接收Put之前進行了major compact，major compact過程會刪除掉delete marker，隨后備集群接收到了這條put，那么這條put在備集群上將沒有機會再delete，將會一直存在。

解決這個問題需要保證任何情況下，Replciation的順序與主集群的mutation順序是一致的，即串行Replication（Serial Replication， backport form v2.1）。例如當Region發(fā)生移動從RegionServer1移動到了RegionServer2，那么RegionServer2應(yīng)當?shù)却齊egionServer1將此region的所有數(shù)據(jù)推送完，再進行推送。

串行Replciation使用Barrier和lastPushedSequenceId來解決這個問題。每當Region發(fā)生Open時，都會在meta表中記錄一個新的Barrier，這個Barrier為當前Region的最大SequenceId + 1。lastPushedSequenceId為當前region推送到備集群的SequenceId，在Replciation的過程中，每個batch成功，會在Zookeeper中記錄最大的SequenceId，即lastPushedSequenceId。

?

?

如圖所示，一個Region從RegionServer1移動到RegionServer2，又到RegionServer3，發(fā)生多次Region Open，記錄了多個Barrier，構(gòu)成多個Range：[ Barrier(n) , Barrier(n+1) )。期間有多個mutation操作記錄的SequenceId：s1、s2、s3、……

RegionServer在進行數(shù)據(jù)Replication前，首先檢查lastPushedSequenceId 是否大于自己區(qū)間的起始Barrier。例如上圖中RegionServer3會首先檢查，當lastPushedSequenceId >= Barrier1 – 1時才會進行Replication，而此lastPushedSequenceId = s2，則說明lastPushedSequenceId所在Range的RegionServer2正在進行Replication，那么RegionServer3需要等待。這樣就保證了數(shù)據(jù)抵達備集群的順序與主集群的寫入順序是相同的。

?

總結(jié)與展望

?

JDHBase在不斷吸收業(yè)界異地災(zāi)備經(jīng)驗的同時，也經(jīng)過一系列的實踐和演進，目前SLA已經(jīng)能夠達到99.98%，從毫無異地容災(zāi)措施到完善的監(jiān)控、告警、切換、一致性保障機制，為業(yè)務(wù)提供穩(wěn)定可靠的存儲服務(wù)。

同時隨著業(yè)務(wù)的增多和數(shù)據(jù)量的增大，集群規(guī)模也越來越大，仍面臨一些挑戰(zhàn)，未來我們在異地災(zāi)備方面將會著力在同步的Replication、去zookeeper依賴、客戶端視角自動切換、降低數(shù)據(jù)冗余等方面繼續(xù)提升可靠性及穩(wěn)定性。

?

?

References

1、https://hbase.apache.org/book.html#_cluster_replication

2、https://mapr.com/blog/in-depth-look-hbase-architecture/

3、hhttps://issues.apache.org/jira/browse/HBASE-20360

4、https://issues.apache.org/jira/browse/HBASE-20046

總結(jié)

以上是生活随笔為你收集整理的京东JDHBase异地多活实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。