騰訊徐春明：網際網路金融行業HBase實踐與創新

本文根據徐春明老師在2018年5月11日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

講師簡介：

                                             

 

徐春明——騰訊金融與支付資料庫平臺組負責人，在資料庫行業有超過10年的工作經驗，擅長MySQL資料庫運維、核心開發。近期深入研究HBase相關技術，負責HBase技術在騰訊支付場景的落地。 

摘要：

本次分享講述的是關係型資料庫在騰訊金融支付場景下遇到的挑戰，選擇HBase背後的主要原因以及我們是如何打造高效能、高可靠、高可用的HBase資料中心。最後是關於HBase在網際網路金融業務方面遇到的挑戰和解決之道。

分享大綱：

1、關聯式資料庫挑戰—擴充套件性、可維護性、易用性

2、如何打造HBase中心—高效能、可靠、高可用

3、HBase挑戰和應對—業務侷限、二級索引、叢集複製

正文：

一．關聯式資料庫挑戰—擴充套件性、可維護性、易用性

財付通是騰訊在2005年成立的， 2013年逐漸淡出使用者視野，之前負責解決在PC端的支付業務。現階段財付通主要是為微信紅包提供中後端業務以及服務金融業務。2005年，騰訊的資料庫還比較單一，基本上都是MySQL，每秒的峰值交易量只有幾百，當時我們著重解決資料安全、可容性以及跨城容災等問題。但2015年因微信紅包的出現，交易量峰值一年之內漲了100倍，我們遇到了效能、容災以及可用性等方面的諸多問題，團隊為解決這些問題做了非常多的工作，最終建立了一個交易系統+歷史資料的基本系統架構。

 以上這個架構主要運用了MySQL的一些元件，包括三種引擎，左邊是實時庫叢集，這個叢集使用的是InnoDB引擎，叢集中的裝置效能很好，IO能力強，記憶體大，CPU也很好，裡面有幾百套的分組，因為微信支付的交易很複雜，涉及到分散式事務、同城容災、跨城容災等等很多方面。當時我們使用的是MySQL和InnoDB資料庫，使用過程中發現只要出現一個節日，我們線上的容量就會不夠，因為高效能的伺服器容量是有限的。

而且節日的出現導致交易峰值很高，所以我們出現了鋸齒形的峰值圖。除此之外，資料庫容量也在飛快的增長，基於這些問題我們的解決辦法是進行刪除不重要欄位、優化索引、減少資料內容等操作，將歷史資料遷移到歷史庫叢集中，2015年之前我們還不是實時遷移，一般是第二天低峰期批量匯出匯入然後再刪除。

這樣的方式雖然能解決我們線上交易的高併發海量資料問題，但是在遇到需要歷史資料的情況時依舊會出現很多問題。

我們遇到的挑戰主要是上圖的幾個方面，第一個水平擴充套件，因為國家要求金融機構儲存交易資料，隨著交易資料與日俱增，單機效能儲存很容易達到瓶頸，架構難以適應目前資料儲存規模，需要考慮資料拆分，但傳統DB拆分困難，工作量很大週期又長。

第二個是資料遷移，我們設定資料遷移策略，定期從交易DB裡將資料寫入到歷史DB中，但其中分庫分表的遷移策略很複雜，造成了上一層Spider的配置非常複雜，容易出錯，所以在業務使用的時候就出現了好幾次查不出資料，導致業務資料不完整。

再一個問題歷史DB一般是廉價的裝置，容量很大也很容易出故障，雖然我們有多個歷史庫備機，直接通過複製同步資料來解決系統問題，但資料量實在太大，執行過程中發現備機總是追不上主機，一旦主機出現故障，備機由於延遲不能對外作為主機使用，只能去修復故障的主機，存在比較大的風險。

在批量查詢上，傳統歷史DB採用TokuDB引擎，資料高度壓縮，磁碟IO、記憶體效能比較差，大批量的資料掃面對單機效能影響很大，容易拖垮歷史庫。業務查詢方面也出現了查詢資料不準、資料錯亂等等問題。

總的來說，業務開始執行之後，資料庫總是出現問題，導致了很多資料庫口碑的負面影響。

我們當時解決方案就是對比資料庫來選擇效能更好的資料庫，我們對比了Redis、MongoDB還有 HBase，但最終選擇了HBase，主要是看中了它寫高讀低的特點，這個對我們其實影響不大，我們對歷史資料的查詢比較少，也沒有像對線上交易業務的要求那麼高。第二是它的擴充套件性靈活，只要HBase的叢集穩定，它的擴容就非常容易，HBase的安全性也高，這樣團隊需要做的事情就少了很多，我們可以有更多的精力放在其他方面的工作。

二、如何打造HBase中心—高效能、可靠、高可用

選擇HBase資料中心之後，接下來就是如何打造的問題，當時團隊確定了100萬+每秒輸入，可用率99.9%、0條記錄丟失、錯誤的目標，具體實施步驟分兩步走：

首先要將資料錄入到HBase中，我們的資料來源是MySQL，資料經過日誌解析系統DBSync之後快取再寫入HBase。中間過程本來沒有這麼複雜，當時是負責資料探勘的leader找到我，因為他們每次資料統計不準確，接到的投訴比較多。正好我們從成本角度考慮，不用申請這部分伺服器，可以快速將資料寫入到自己的HBase。資料錄入後該如何查詢呢？我們交易業務基本用c++實現，HBase用的是Java語言，HBase的thrift可用於跨語言的資料傳輸，所以我們就基於thrift做了一個API來解決跨語言問題。

對於業務流程該如何使用呢？我們不僅僅把HBase當做存歷史資料的平臺，業務流程除開賬務DB外，還有其他交易相關的DB，它們都有同一個問題，容量很容易爆滿，為了將HBase發揮更大的用處，在特定的場景下，比如一個月前的歷史退款，線上資料不可能儲存這麼久，如果時間有一個月以上的退款，我們從HBase查退款，將其寫入MySQL，核心的退款流程和金融流程直接在MySQL做，這樣一來對業務的改動最小，方便業務操作。

HBase的寫入原理是基於LSM思想，先把資料寫入記憶體之後返回，通過非同步方式再落盤，但是這樣在磁碟就有很多小檔案，查詢的效能就會非常差。所以，還需要將磁碟上的小檔案compaction，減少檔案個數。考慮之前積壓的很多compaction任務，我們把small compact執行緒條加大。再一個是調整WAL日誌的引數，做過關係型資料庫的人可能清楚，HBase裡有四種方式，第一種是直接寫記憶體不寫硬碟，第二種是非同步的落盤，第三種就是寫入作業系統不落盤，第四種是實時寫盤。結合效能與資料可靠性，我們採用寫入作業系統不落盤的方式，考慮有三個副本同時出現三連級故障的可能性比較低，降低IO壓力和時延。再有就是減小regionserver堆疊記憶體大小，因為我們業務寫入量實在太頻繁，而cache查詢命中率真非常低，大概只有10%到15%，所以我們將記憶體全部分給寫入，來提高寫入的量。因為是批量寫入型業務，我們可以根據需求調整客戶端批量寫入記錄數來提高寫的效能。

優化之後，壓測時達到了每秒150萬+次寫入，達到了很不錯的效果。

之後是讀的優化，我們用的伺服器硬體很差，運作率很低，所有的查詢基本全靠磁碟的IO硬能力去抗。LSM思想有個缺點，就是檔案數太多影響查詢效能，假如要查詢rowkey=100的資料，檔案數有100個，由於每個檔案裡可能都有rowkey=100的記錄，那麼我們就要掃描100個檔案，耗費時間很長。我們的解決方法是減少在region下的檔案數，定期合併檔案，把小檔案整合成大檔案。第二個就是重點隔離，我們把一些表單獨隔離，做一個組，去減小耦合，而且組內機器只允許制定表讀寫請求，避免不同表之間的相互影響。還有引數優化，我們一開始建了很多region表，這樣對整個叢集壓力太大，所以就減少小表，控制其數量。再有一個就是業務按照優先順序分等級，不同的級別的業務不同處理，有些索引表可以按年建，有些表可以按月建。最後是硬體升級，重點組配置更高效能的伺服器。

優化之後，查詢時耗從開始的260毫秒下降到60毫秒，查詢時耗曲線也逐漸平緩。

在高可用方面，第一個HBase本身必須保證可用，這是最基礎的點，避免Full GC，避免Region Server單個Region阻塞不可用。第二當機器出現故障，怎麼做才不會影響整個叢集的讀寫？我們使用快速剔除機制，避免單臺伺服器負載高影響叢集，第三考慮網路不可用、機房故障情況，為此建立主、備叢集，一個叢集裡有三個副本，那麼就共有六個副本，成本很高，我們考慮隔三個月時間就減少到兩個副本，以此來節約成本。第四避免雪崩，無論是Thrift Server還是RPC的呼叫，操作時間都是比較長的， 這就需要縮短Thrift Server超時時間，減少重試次數。最後按業務重要級別分組，減少和其他機器的耦合。

上圖是高可用單點保障的流程圖：從客戶端寫入一個資料，查閱Meta表獲取RS位置,把資料寫到RegionServer中，然後非同步寫到Hadoop層去同步資料。可以看到在叢集內只有Region Server是單點，其它元件都有高可用方案。當Region Server故障時，叢集內遷移恢復一般需要幾分鐘，對於OLTP業務來說是不可接受的。可選擇的方案是業務快速遷移到備叢集，或者使用region replica。

我們通過三種方法來保證資料的準確性，第一種是資料對賬，在金融系統中都會有資料對賬，我相信無論什麼系統都會有bug，對賬十分關鍵不能出錯，我們有10分鐘增量對賬，有冗餘資料對賬，要求資料寫入來源IP與核對IP分開，來源DB於對賬DB分開。第二個從流程規範來降低人為失誤，通過一些系統化的方法來運維。第三個是提高監控效率，加了秒級監控，如果出現問題能快速發現馬上解決，出現對賬異常立刻上報神盾安全系統。這樣通過上面的三種方法，我們把資料的準確性提高了一個量級。

這裡單獨講下update的特殊處理，金融業務對資料的處理分兩種，第一種是直接對映的，像使用者資金流失這種比較簡單。比較困難的是第二種時間批量對賬，比如像一些餘額和某些訂單的狀態，我們一天的資料量有幾百億，該如何應對平均一秒幾十萬的對賬呢，為此係統加了修改時間，使得對賬更加準確，但同時會造成資料的冗餘，比如一個單號對應我們交易系統裡的一條記錄，但在HBase中沒有update，全部是對映，這樣就會有兩條記錄，這樣狀態下退款是不能成功的，為解決這個問題，我們將MySQL binlog中update拆分成delete + insert兩條訊息，使得HBase中保留一條記錄。

但這樣還有一個問題，有可能在同一秒鐘有兩次記錄，就是說同一個單號在一秒鐘內完成交易，拆分資料時，有可能導致兩條資料記錄都刪掉，如果沒有一定的併發量，這個問題是不會出現的。我們在處理這個問題時採取在拆分時加個序號，並且保證insert在delete的後面，這樣就能確保留下一條記錄。

我們在實際運用HBase過程中，也遇到了很多其他問題。第一個是遇到HBase讀寫執行緒佇列分開，因為我們寫入量遠遠多於讀的量，比如退款業務只有寫沒有讀，我們調整了hbase.ipc.server.callqueue.read.share=0.3的引數，來保證一定的讀寫執行緒。還遇到某一臺DataNode負載高導致整個叢集寫入量下降非常明顯，我們增加了秒級監控可以快速發現，快速遷移region解決。

之後還有可維護性方面的問題，HBase有些配置不能動態修改配置、不支援命令檢視HBase叢集運營情況、缺少彙總統計功能。還有就是容量均衡，我們的資料量在不斷增加，我們有幾十臺伺服器磁碟容量已經用了99%，有的伺服器容量使用還不到1%。所以需要在伺服器間遷移資料。可以不在HBase層操作，而是從hdfs層停datanode節點，讓namenode遷移。

總的來說，雖然HBase有一些缺點，但HBase的優勢更加明顯，它效能穩定有利於更好地解放人力，節約成本。

三、HBase挑戰和應對—業務侷限、二級索引、叢集複製

下面是我對於HBase的想法， 現階段HBase的應用場景只有兩種，有比較大的侷限性，因為它不支援SQL，不支援跨行跨表事務，不支援二級索引，而且讀時延大。它不能用在OLTP（On-Line Transaction Processing聯機事務處理過程）業務，比如支付業務的核心流程，但適合存放歷史資料，處理歷史資料的對賬、歷史資料的回溯等需求。

 那如何來解決事務問題呢？第一個，HBase雖然不支援跨行跨表事務，但可以多表變單表，實施單表設計與HBase單行事務。所以在處理資料表的事務時，儘量多表換單表，避免分散式事務。

 第二個事務是業務分散式事務，如果做金融業務，在HBase中改動難度太大，可以在業務層進行改動，採用兩階段提交協議，分成P,C,F階段。事務管理器控制事務的提交或者回滾。資源管理器對應表，一張表拆分多個資源管理器，採用有鎖方案。事務管理器無狀態，高可用方案比較成熟。資源管理器有狀態，可以是M-S方案，但也可以設計成M-M方案，無論是分散式還是單機，把HBase進行重組，利用HBase的單行事務功能來控制併發。

下面是具體的例子

 第三個是開源分散式事務框架。主要是兩種OMID和Percolator，共同點是兩階段分散式。不同點是OMID有個全域性事務，通過它來控制併發，控制哪個事務該回滾。Percolator主要是運用Hbase協處理器的技術，實踐起來比較困難。

上圖是協處理器的應用，第一個是Phoenix，它支援sql、二級索引，通過Coprocessor實現，但它不穩定，資料量大的情況容易造成HBase崩潰。第二個Coprocessor實現，使用Observer實現在寫主表前先寫索引表，最後是時間庫表，表設計成按月或者按日分表，新建索引時不用copy歷史資料。

HBase有複製的功能，但在使用過程中發現它不穩定，我們後來通過應用來實現雙寫功能。

上圖是HBase和Hadoop支援的隔離方案，雖然能在一定程度上做到了隔離，但這種隔離不徹底，耦合比較強，定位問題比較複雜，依舊不能實現業務上隔離。

最後，談一下資料庫的目標和方向。無論是傳統的關係型資料庫還是分散式資料庫，努力的方向就是提供高可用、高效能、高併發、好用、易擴充套件的資料服務。目前市面上的資料庫非常多，但所有的資料庫或多或少總有幾個特性實現得差強人意，所以也沒有出現“一統江湖”的資料庫，導致資料庫應用出現百花齊放的局面，這也是各個資料庫團隊努力的方向和動力。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31547542/viewspace-2213514/，如需轉載，請註明出處，否則將追究法律責任。