本文根據(jù)徐春明老師在2018年5月11日【第九屆中國數(shù)據(jù)庫技術(shù)大會(DTCC)】現(xiàn)場演講內(nèi)容整理而成。

峽江網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)從2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

講師簡介：

                                             

 

徐春明——騰訊金融與支付數(shù)據(jù)庫平臺組負責人，在數(shù)據(jù)庫行業(yè)有超過10年的工作經(jīng)驗，擅長MySQL數(shù)據(jù)庫運維、內(nèi)核開發(fā)。近期深入研究HBase相關(guān)技術(shù)，負責HBase技術(shù)在騰訊支付場景的落地。 

摘要：

本次分享講述的是關(guān)系型數(shù)據(jù)庫在騰訊金融支付場景下遇到的挑戰(zhàn)，選擇HBase背后的主要原因以及我們是如何打造高性能、高可靠、高可用的HBase數(shù)據(jù)中心。最后是關(guān)于HBase在互聯(lián)網(wǎng)金融業(yè)務(wù)方面遇到的挑戰(zhàn)和解決之道。

分享大綱：

1、關(guān)系數(shù)據(jù)庫挑戰(zhàn)—擴展性、可維護性、易用性

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

3、HBase挑戰(zhàn)和應(yīng)對—業(yè)務(wù)局限、二級索引、集群復(fù)制

正文：

一．關(guān)系數(shù)據(jù)庫挑戰(zhàn)—擴展性、可維護性、易用性

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

 以上這個架構(gòu)主要運用了MySQL的一些組件，包括三種引擎，左邊是實時庫集群，這個集群使用的是InnoDB引擎，集群中的設(shè)備性能很好，IO能力強，內(nèi)存大，CPU也很好，里面有幾百套的分組，因為微信支付的交易很復(fù)雜，涉及到分布式事務(wù)、同城容災(zāi)、跨城容災(zāi)等等很多方面。當時我們使用的是MySQL和InnoDB數(shù)據(jù)庫，使用過程中發(fā)現(xiàn)只要出現(xiàn)一個節(jié)日，我們線上的容量就會不夠，因為高性能的服務(wù)器容量是有限的。

而且節(jié)日的出現(xiàn)導(dǎo)致交易峰值很高，所以我們出現(xiàn)了鋸齒形的峰值圖。除此之外，數(shù)據(jù)庫容量也在飛快的增長，基于這些問題我們的解決辦法是進行刪除不重要字段、優(yōu)化索引、減少數(shù)據(jù)內(nèi)容等操作，將歷史數(shù)據(jù)遷移到歷史庫集群中，2015年之前我們還不是實時遷移，一般是第二天低峰期批量導(dǎo)出導(dǎo)入然后再刪除。

這樣的方式雖然能解決我們線上交易的高并發(fā)海量數(shù)據(jù)問題，但是在遇到需要歷史數(shù)據(jù)的情況時依舊會出現(xiàn)很多問題。

我們遇到的挑戰(zhàn)主要是上圖的幾個方面，第一個水平擴展，因為國家要求金融機構(gòu)保存交易數(shù)據(jù)，隨著交易數(shù)據(jù)與日俱增，單機性能存儲很容易達到瓶頸，架構(gòu)難以適應(yīng)目前數(shù)據(jù)存儲規(guī)模，需要考慮數(shù)據(jù)拆分，但傳統(tǒng)DB拆分困難，工作量很大周期又長。

第二個是數(shù)據(jù)遷移，我們設(shè)置數(shù)據(jù)遷移策略，定期從交易DB里將數(shù)據(jù)寫入到歷史DB中，但其中分庫分表的遷移策略很復(fù)雜，造成了上一層Spider的配置非常復(fù)雜，容易出錯，所以在業(yè)務(wù)使用的時候就出現(xiàn)了好幾次查不出數(shù)據(jù)，導(dǎo)致業(yè)務(wù)數(shù)據(jù)不完整。

再一個問題歷史DB一般是廉價的設(shè)備，容量很大也很容易出故障，雖然我們有多個歷史庫備機，直接通過復(fù)制同步數(shù)據(jù)來解決系統(tǒng)問題，但數(shù)據(jù)量實在太大，運行過程中發(fā)現(xiàn)備機總是追不上主機，一旦主機出現(xiàn)故障，備機由于延遲不能對外作為主機使用，只能去修復(fù)故障的主機，存在比較大的風險。

在批量查詢上，傳統(tǒng)歷史DB采用TokuDB引擎，數(shù)據(jù)高度壓縮，磁盤IO、內(nèi)存性能比較差，大批量的數(shù)據(jù)掃面對單機性能影響很大，容易拖垮歷史庫。業(yè)務(wù)查詢方面也出現(xiàn)了查詢數(shù)據(jù)不準、數(shù)據(jù)錯亂等等問題。

總的來說，業(yè)務(wù)開始運行之后，數(shù)據(jù)庫總是出現(xiàn)問題，導(dǎo)致了很多數(shù)據(jù)庫口碑的負面影響。

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

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

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

首先要將數(shù)據(jù)錄入到HBase中，我們的數(shù)據(jù)源是MySQL，數(shù)據(jù)經(jīng)過日志解析系統(tǒng)DBSync之后緩存再寫入HBase。中間過程本來沒有這么復(fù)雜，當時是負責數(shù)據(jù)挖掘的leader找到我，因為他們每次數(shù)據(jù)統(tǒng)計不準確，接到的投訴比較多。正好我們從成本角度考慮，不用申請這部分服務(wù)器，可以快速將數(shù)據(jù)寫入到自己的HBase。數(shù)據(jù)錄入后該如何查詢呢？我們交易業(yè)務(wù)基本用c++實現(xiàn)，HBase用的是Java語言，HBase的thrift可用于跨語言的數(shù)據(jù)傳輸，所以我們就基于thrift做了一個API來解決跨語言問題。

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

HBase的寫入原理是基于LSM思想，先把數(shù)據(jù)寫入內(nèi)存之后返回，通過異步方式再落盤，但是這樣在磁盤就有很多小文件，查詢的性能就會非常差。所以，還需要將磁盤上的小文件compaction，減少文件個數(shù)?？紤]之前積壓的很多compaction任務(wù)，我們把small compact線程條加大。再一個是調(diào)整WAL日志的參數(shù)，做過關(guān)系型數(shù)據(jù)庫的人可能清楚，HBase里有四種方式，第一種是直接寫內(nèi)存不寫硬盤，第二種是異步的落盤，第三種就是寫入操作系統(tǒng)不落盤，第四種是實時寫盤。結(jié)合性能與數(shù)據(jù)可靠性，我們采用寫入操作系統(tǒng)不落盤的方式，考慮有三個副本同時出現(xiàn)三連級故障的可能性比較低，降低IO壓力和時延。再有就是減小regionserver堆棧內(nèi)存大小，因為我們業(yè)務(wù)寫入量實在太頻繁，而cache查詢命中率真非常低，大概只有10%到15%，所以我們將內(nèi)存全部分給寫入，來提高寫入的量。因為是批量寫入型業(yè)務(wù)，我們可以根據(jù)需求調(diào)整客戶端批量寫入記錄數(shù)來提高寫的性能。

優(yōu)化之后，壓測時達到了每秒150萬+次寫入，達到了很不錯的效果。

之后是讀的優(yōu)化，我們用的服務(wù)器硬件很差，運作率很低，所有的查詢基本全靠磁盤的IO硬能力去抗。LSM思想有個缺點，就是文件數(shù)太多影響查詢性能，假如要查詢rowkey=100的數(shù)據(jù)，文件數(shù)有100個，由于每個文件里可能都有rowkey=100的記錄，那么我們就要掃描100個文件，耗費時間很長。我們的解決方法是減少在region下的文件數(shù)，定期合并文件，把小文件整合成大文件。第二個就是重點隔離，我們把一些表單獨隔離，做一個組，去減小耦合，而且組內(nèi)機器只允許制定表讀寫請求，避免不同表之間的相互影響。還有參數(shù)優(yōu)化，我們一開始建了很多region表，這樣對整個集群壓力太大，所以就減少小表，控制其數(shù)量。再有一個就是業(yè)務(wù)按照優(yōu)先級分等級，不同的級別的業(yè)務(wù)不同處理，有些索引表可以按年建，有些表可以按月建。最后是硬件升級，重點組配置更高性能的服務(wù)器。

優(yōu)化之后，查詢時耗從開始的260毫秒下降到60毫秒，查詢時耗曲線也逐漸平緩。

在高可用方面，第一個HBase本身必須保證可用，這是最基礎(chǔ)的點，避免Full GC，避免Region Server單個Region阻塞不可用。第二當機器出現(xiàn)故障，怎么做才不會影響整個集群的讀寫？我們使用快速剔除機制，避免單臺服務(wù)器負載高影響集群，第三考慮網(wǎng)絡(luò)不可用、機房故障情況，為此建立主、備集群，一個集群里有三個副本，那么就共有六個副本，成本很高，我們考慮隔三個月時間就減少到兩個副本，以此來節(jié)約成本。第四避免雪崩，無論是Thrift Server還是RPC的調(diào)用，操作時間都是比較長的， 這就需要縮短Thrift Server超時時間，減少重試次數(shù)。最后按業(yè)務(wù)重要級別分組，減少和其他機器的耦合。

上圖是高可用單點保障的流程圖：從客戶端寫入一個數(shù)據(jù)，查閱Meta表獲取RS位置,把數(shù)據(jù)寫到RegionServer中，然后異步寫到Hadoop層去同步數(shù)據(jù)。可以看到在集群內(nèi)只有Region Server是單點，其它組件都有高可用方案。當Region Server故障時，集群內(nèi)遷移恢復(fù)一般需要幾分鐘，對于OLTP業(yè)務(wù)來說是不可接受的。可選擇的方案是業(yè)務(wù)快速遷移到備集群，或者使用region replica。

我們通過三種方法來保證數(shù)據(jù)的準確性，第一種是數(shù)據(jù)對賬，在金融系統(tǒng)中都會有數(shù)據(jù)對賬，我相信無論什么系統(tǒng)都會有bug，對賬十分關(guān)鍵不能出錯，我們有10分鐘增量對賬，有冗余數(shù)據(jù)對賬，要求數(shù)據(jù)寫入來源IP與核對IP分開，來源DB于對賬DB分開。第二個從流程規(guī)范來降低人為失誤，通過一些系統(tǒng)化的方法來運維。第三個是提高監(jiān)控效率，加了秒級監(jiān)控，如果出現(xiàn)問題能快速發(fā)現(xiàn)馬上解決，出現(xiàn)對賬異常立刻上報神盾安全系統(tǒng)。這樣通過上面的三種方法，我們把數(shù)據(jù)的準確性提高了一個量級。

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

但這樣還有一個問題，有可能在同一秒鐘有兩次記錄，就是說同一個單號在一秒鐘內(nèi)完成交易，拆分數(shù)據(jù)時，有可能導(dǎo)致兩條數(shù)據(jù)記錄都刪掉，如果沒有一定的并發(fā)量，這個問題是不會出現(xiàn)的。我們在處理這個問題時采取在拆分時加個序號，并且保證insert在delete的后面，這樣就能確保留下一條記錄。

我們在實際運用HBase過程中，也遇到了很多其他問題。第一個是遇到HBase讀寫線程隊列分開，因為我們寫入量遠遠多于讀的量，比如退款業(yè)務(wù)只有寫沒有讀，我們調(diào)整了hbase.ipc.server.callqueue.read.share=0.3的參數(shù)，來保證一定的讀寫線程。還遇到某一臺DataNode負載高導(dǎo)致整個集群寫入量下降非常明顯，我們增加了秒級監(jiān)控可以快速發(fā)現(xiàn)，快速遷移region解決。

之后還有可維護性方面的問題，HBase有些配置不能動態(tài)修改配置、不支持命令查看HBase集群運營情況、缺少匯總統(tǒng)計功能。還有就是容量均衡，我們的數(shù)據(jù)量在不斷增加，我們有幾十臺服務(wù)器磁盤容量已經(jīng)用了99%，有的服務(wù)器容量使用還不到1%。所以需要在服務(wù)器間遷移數(shù)據(jù)?？梢圆辉贖Base層操作，而是從hdfs層停datanode節(jié)點，讓namenode遷移。

總的來說，雖然HBase有一些缺點，但HBase的優(yōu)勢更加明顯，它性能穩(wěn)定有利于更好地解放人力，節(jié)約成本。

三、HBase挑戰(zhàn)和應(yīng)對—業(yè)務(wù)局限、二級索引、集群復(fù)制

下面是我對于HBase的想法， 現(xiàn)階段HBase的應(yīng)用場景只有兩種，有比較大的局限性，因為它不支持SQL，不支持跨行跨表事務(wù)，不支持二級索引，而且讀時延大。它不能用在OLTP（On-Line Transaction Processing聯(lián)機事務(wù)處理過程）業(yè)務(wù)，比如支付業(yè)務(wù)的核心流程，但適合存放歷史數(shù)據(jù)，處理歷史數(shù)據(jù)的對賬、歷史數(shù)據(jù)的回溯等需求。

 那如何來解決事務(wù)問題呢？第一個，HBase雖然不支持跨行跨表事務(wù)，但可以多表變單表，實施單表設(shè)計與HBase單行事務(wù)。所以在處理數(shù)據(jù)表的事務(wù)時，盡量多表換單表，避免分布式事務(wù)。

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

下面是具體的例子

 第三個是開源分布式事務(wù)框架。主要是兩種OMID和Percolator，共同點是兩階段分布式。不同點是OMID有個全局事務(wù)，通過它來控制并發(fā)，控制哪個事務(wù)該回滾。Percolator主要是運用Hbase協(xié)處理器的技術(shù)，實踐起來比較困難。

上圖是協(xié)處理器的應(yīng)用，第一個是Phoenix，它支持sql、二級索引，通過Coprocessor實現(xiàn)，但它不穩(wěn)定，數(shù)據(jù)量大的情況容易造成HBase崩潰。第二個Coprocessor實現(xiàn)，使用Observer實現(xiàn)在寫主表前先寫索引表，最后是時間庫表，表設(shè)計成按月或者按日分表，新建索引時不用copy歷史數(shù)據(jù)。

HBase有復(fù)制的功能，但在使用過程中發(fā)現(xiàn)它不穩(wěn)定，我們后來通過應(yīng)用來實現(xiàn)雙寫功能。

上圖是HBase和Hadoop支持的隔離方案，雖然能在一定程度上做到了隔離，但這種隔離不徹底，耦合比較強，定位問題比較復(fù)雜，依舊不能實現(xiàn)業(yè)務(wù)上隔離。

最后，談一下數(shù)據(jù)庫的目標和方向。無論是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫還是分布式數(shù)據(jù)庫，努力的方向就是提供高可用、高性能、高并發(fā)、好用、易擴展的數(shù)據(jù)服務(wù)。目前市面上的數(shù)據(jù)庫非常多，但所有的數(shù)據(jù)庫或多或少總有幾個特性實現(xiàn)得差強人意，所以也沒有出現(xiàn)“一統(tǒng)江湖”的數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)庫應(yīng)用出現(xiàn)百花齊放的局面，這也是各個數(shù)據(jù)庫團隊努力的方向和動力。

新聞標題：騰訊徐春明：互聯(lián)網(wǎng)金融行業(yè)HBase實踐與創(chuàng)新-創(chuàng)新互聯(lián)
網(wǎng)址分享：http://chinadenli.net/article48/dessep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、網(wǎng)站導(dǎo)航、微信公眾號、面包屑導(dǎo)航、品牌網(wǎng)站建設(shè)、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)