億級客戶和PB級數(shù)據(jù)規(guī)模的金融級數(shù)據(jù)庫實戰(zhàn)歷程

導語：微眾銀行在2014年成立之時，就非常有前瞻性的確立了分布式架構的基礎架構。當時，騰訊有一款金融級的分布式數(shù)據(jù)庫產(chǎn)品TDSQL，其業(yè)務場景和對數(shù)據(jù)庫的可靠性要求，和銀行場景非常類似。微眾銀行和騰訊TDSQL團隊合作，共同將TDSQL打造為適合銀行核心場景使用的金融級分布式數(shù)據(jù)庫產(chǎn)品，并將TDSQL用于微眾銀行的核心系統(tǒng)數(shù)據(jù)庫。本文是對整個實踐歷程的總結。

一、背景介紹

微眾銀行在2014年成立之時，就非常有前瞻性的確立了微眾銀行的IT基礎架構的方向：摒棄傳統(tǒng)的基于商業(yè)IT產(chǎn)品的集中架構模式，走互聯(lián)網(wǎng)模式的分布式架構。眾所周知，傳統(tǒng)銀行IT架構體系非常依賴于傳統(tǒng)的商業(yè)數(shù)據(jù)庫，商業(yè)存儲以及大中型服務器設備，每年也需要巨大的IT費用去維護和升級，同時這種集中式的架構，也不便于進行高效的實現(xiàn)水平擴展。從過往經(jīng)驗來看，當時除了oracle等少數(shù)傳統(tǒng)的商業(yè)數(shù)據(jù)庫，能滿足金融級銀行場景的數(shù)據(jù)庫產(chǎn)品并不多。

當時，騰訊有一款金融級的分布式數(shù)據(jù)庫產(chǎn)品TDSQL，主要承載騰訊內部的計費和支付業(yè)務，其業(yè)務場景和對數(shù)據(jù)庫的可靠性要求，和銀行場景非常類似，同時也經(jīng)受了騰訊海量計費業(yè)務場景的驗證。

微眾銀行基礎架構團隊，經(jīng)過多輪的評估和測試，最終確定和騰訊TDSQL團隊合作，共同將TDSQL打造為適合銀行核心場景使用的金融級分布式數(shù)據(jù)庫產(chǎn)品，并將TDSQL用于微眾銀行的核心系統(tǒng)數(shù)據(jù)庫。

二、Why TDSQL？

為什么會選用TDSQL，作為微眾銀行的核心數(shù)據(jù)庫呢？本章節(jié)將會詳細介紹TDSQL架構、以及TDSQL的核心特性，看看TDSQL是如何滿足了金融級場景的數(shù)據(jù)庫要求。

1.TDSQL架構介紹

TDSQL是基于MySQL/Mariadb社區(qū)版本打造的一款金融級分布式數(shù)據(jù)庫集群方案。在內核層面，TDSQL針對MySQL 社區(qū)版本和Mariadb 社區(qū)版本的內核，在復制模塊做了系統(tǒng)級優(yōu)化，使得其具備主備副本數(shù)據(jù)強一致同步的特性，極大提升了數(shù)據(jù)安全性，同時相對原生的半同步復制機制，TDSQL強一致復制的性能也有極大提升。TDSQL集成了TDSQL Agent、TDSQL SQLEngineSQLEngine、TDSQL Scheduler等多個模塊，實現(xiàn)了讀寫分離、AutoSharding、自動主備強一致性切換、自動故障修復、實時監(jiān)控、實時冷備等一系列功能。TDSQL架構模型如下面兩張圖所示。

圖 TDSQL架構模型與SET模型

我們可以 從橫向和縱向兩個維度來理解TDSQL的架構。

橫向是TDSQL的請求處理路徑：請求通過APP發(fā)出，經(jīng)過負載均衡模塊，轉發(fā)到TDSQL SQLEngine集群；TDSQL SQLEngine收到請求后，進行請求解析，然后轉發(fā)到set單元內的數(shù)據(jù)庫實例節(jié)點上（寫請求到master，讀請求可以到master或slave）；數(shù)據(jù)庫實例處理好請求后，回包給TDSQL SQLEngine，TDSQL SQLEngine再通過負載均衡模塊回包給app。

縱向是TDSQL集群的管理路徑：TDSQL的一個管理單元稱為一個set，每個set單元的每個數(shù)據(jù)庫實例上，都會部署一個TDSQL Agent模塊。Agent模塊會收集所在數(shù)據(jù)庫實例的所有監(jiān)控信息（包括節(jié)點主備角色信息/節(jié)點存活狀態(tài)/請求量/TPS/CPU負載/IO負載/慢查詢/連接數(shù)/容量使用率等等），上報到ZooKeeper集群；ZooKeeper相當于整個TDSQL集群元數(shù)據(jù)存儲管理中心，保存了集群所有元數(shù)據(jù)信息；TDSQL Scheduler模塊會監(jiān)控ZooKeeper的所存儲的上報信息，并根據(jù)集群狀態(tài)啟動不同的調度任務，相當于TDSQL集群的大腦，負責整個集群的管理和調度。

2. TDSQL noshard 與 shard 模式

TDSQL提供了noshard與shard兩種使用模式，如下圖所示。

圖 TDSQL noshard與shard模式

所謂noshard模式，就是單實例模式，不做自動的分庫分表，在語法和功能上完全兼容于MySQL，缺點是只支持垂直擴容，這會受限于單實例服務器的性能和容量上限，無法進行水平擴展。

Shard模式即AutoSharding模式。通過TDSQL SQLEngine模塊，實現(xiàn)數(shù)據(jù)庫的Sharding和分布式事務功能，底層的數(shù)據(jù)打散在多個數(shù)據(jù)庫實例上，對應用層還是統(tǒng)一的單庫視圖。Shard模式可以實現(xiàn)容量和性能的水平擴展，通過兩階段XA支持分布式事務和各種關聯(lián)操作，但是目前還不支持存儲過程，同時在建表的時候需要業(yè)務指定shard key，對部分業(yè)務開發(fā)來說覺得會有一定的侵入性 。

微眾銀行當時在做系統(tǒng)架構的時候充分考慮了是采用shard版本的純分布式數(shù)據(jù)庫還是從應用層的角度來做分布式，通過大量的調研分析，最終覺得采用 應用做分布式是最可控，最安全，最靈活，最可擴展的模式，從而設計了基于DCN的分布式可擴展架構，通過在應用層做水平拆分，數(shù)據(jù)庫采用TDSQL noshard模式，保證了數(shù)據(jù)庫架構的簡潔性和業(yè)務層兼容性，這個后面會詳述。

3. 主備強一致切換與秒級恢復

TDSQL通過針對MySQL內核源碼的定制級優(yōu)化，實現(xiàn)真正意義上的多副本強一致性復制，通過主備部署模式，可以實現(xiàn)RPO=0，即數(shù)據(jù)0丟失，這對于金融場景是至關重要也是最基礎的要求；同時基于TDSQL Agent和Scheduler等模塊，也實現(xiàn)了自動化的主備強一致切換，在30秒內可以完成整個主備切換流程，實現(xiàn)故障RTO的秒級恢復。

4. Watch節(jié)點模式

TDSQL slave節(jié)點提供了兩種角色，一種是follower節(jié)點，一種是watch節(jié)點。Fllower節(jié)點與watch節(jié)點都從master節(jié)點實時同步數(shù)據(jù)，但watch節(jié)點不參與主備選舉和主備切換，只作為觀察者同步數(shù)據(jù)。Follower節(jié)點和watch節(jié)點的角色可以在線實時調整。

5. 自動化監(jiān)控與運維

TDSQL配套提供了赤兔管理平臺系統(tǒng)，來支持整個TDSQL集群的可視化、自動化的監(jiān)控和運維功能。如下圖所示，為TDSQL赤兔管理平臺的運行界面。

圖 TDSQL赤兔管理平臺

通過TDSQL赤兔管理平臺，可以實現(xiàn)監(jiān)控數(shù)據(jù)的采集與顯示，告警和策略配置，日常運維操作（主備切換，節(jié)點替換，配置更改等），數(shù)據(jù)庫備份與恢復，慢查詢分析，性能分析等一系列功能，極大的提升了運維效率和運維準確性。

基于以上的TDSQL的架構和特性，我們認為 TDSQL很好了滿足金融業(yè)務場景中對數(shù)據(jù)庫的高可用、高可靠、可運維的要求，同時基于MySQL和X86的軟硬件平臺，也能極大的降低數(shù)據(jù)庫層面的IT成本，從而極大降低戶均成本，非常適用互聯(lián)網(wǎng)時代的新一代銀行架構。

三、基于DCN的分布式擴展架構

前文提到，微眾銀行為了實現(xiàn)業(yè)務規(guī)模的水平擴展，設計了基于DCN的分布式可擴展架構，從而即實現(xiàn)了擴展性，也保證了數(shù)據(jù)庫層面架構以的簡潔性。

DCN，即Data Center Node(數(shù)據(jù)中心節(jié)點)， 是一個邏輯區(qū)域概念，DCN是一個自包含單位， 包括了完整的應用層，接入層和數(shù)據(jù)庫。可以通俗的理解為，一個DCN，即為一個微眾銀行的線上的虛擬分行，這個虛擬分行只承載微眾銀行某個業(yè)務的一部分客戶。通過一定的路由規(guī)則（比如帳戶號分段），將不同的客戶劃分到不同的DCN內。一旦某個DCN所承載的客戶數(shù)達到規(guī)定的上限，那么這個DCN將不再增加新的客戶。這時通過部署新的DCN，來實現(xiàn)容量的水平擴展，保證業(yè)務的持續(xù)快速發(fā)展。

不同的客戶保存在不同的DCN，那么就需要有一個系統(tǒng)來 保留全局的路由信息，記錄某個客戶到底在哪個DCN，這個系統(tǒng)就是 GNS（Global Name Service），應用模塊會先請求GNS，拿到對應客戶的DCN信息，然后再去請求對應的DCN。GNS使用了redis緩存，以保證較高的查詢QPS性能，同時采用TDSQL做持久化存儲，以保證數(shù)據(jù)的安全性。

RMB（Reliable Message Bug），可靠消息總線，是DCN架構的另一個核心模塊，主要負責各個業(yè)務系統(tǒng)之間高效、準確、快速的消息通信。DCN的整體架構如下圖所示。

圖 DCN架構模型

四、微眾銀行IDC架構

有了基于DCN的基礎架構模型，下一步就是基礎物理環(huán)境的建設。微眾銀行經(jīng)過4年多的發(fā)展，目前已發(fā)展成為兩地六中心的架構，如下圖所示。

圖 微眾銀行IDC架構

其中兩地位于深圳和上海，深圳作為生產(chǎn)中心，在深圳同城有5個IDC機房，上海作為跨城異地容災，有1個IDC機房。深圳5個同城IDC，通過多條專線兩兩互聯(lián)，保證極高的網(wǎng)絡質量和帶寬，同時任何兩個IDC之間的距離控制在10~50公里，以保證機房間的網(wǎng)絡ping延遲控制在2ms左右。這一點非常重要，是實現(xiàn)TDSQL同城跨IDC部署的前提。

五、基于TDSQL的同城應用多活

基于以上的 DCN 架構和 IDC 架構，我們設計了TDSQL數(shù)據(jù)庫在微眾銀行的部署架構。如下圖所示。

圖 微眾銀行基于TDSQL的同城多活架構

我們采用同城3副本+跨城2副本的3+2 noshard部署模式。同城3副本為1主2備，分別部署同城的3個IDC中，副本之間采用TDSQL強一致同步，保證同城3 IDC之間的RPO=0，RTO秒級恢復?？绯堑?副本通過同城的一個slave進行異步復制，實現(xiàn)跨城的數(shù)據(jù)容災。基于以上架構，我們在同城可以做到應用多活，即聯(lián)機的業(yè)務流量，可以同時從3個IDC接入，任何一個IDC故障不可用，都可以保證數(shù)據(jù)0丟失，同時在秒級內可以恢復數(shù)據(jù)庫服務。

在同一IDC內，服務器之間的ping延遲通常在0.1ms以內，而同城跨IDC之間服務器的ping延遲會大大增加，那 是否會影響TDSQL主備強同步的性能呢？另外IDC之間的網(wǎng)絡穩(wěn)定性能否保證呢？

我們通過 以下幾個措施來消除或者規(guī)避這個問題。

首先，在基礎設施層面，我們會保證同城的三個IDC之間的距離控制在10~50公里左右，控制網(wǎng)絡延遲在2ms左右；同時在IDC之間建設多條專線，保證網(wǎng)絡傳輸?shù)馁|量和穩(wěn)定性；其次，TDSQL針對這種跨IDC強同步的場景，作了大量的內核級優(yōu)化，比如采用隊列異步化，以及并發(fā)復制等技術。通過基準測試表明，跨IDC強同步對聯(lián)機OLTP的性能影響僅在10%左右。

從我們實際生產(chǎn)運營情況來看，這種同城跨IDC的部署模式，對于聯(lián)機OLTP業(yè)務的性能影響，完全是可以接受的，但對于集中批量的場景，因為累積效應，可能最終會對批量的完成時效產(chǎn)生較大影響。如果批量APP需要跨IDC訪問數(shù)據(jù)庫，那么整個批量期間每次訪問數(shù)據(jù)庫的網(wǎng)絡延遲都會被不斷累積放大，最終會嚴重影響跑批效率。為了解決這個問題，我們利用了TDSQL的watch節(jié)點的機制，針對參與跑批的TDSQL SET，我們在原來一主兩備的基礎上，額外部署了一個與主節(jié)點同IDC的WATCH節(jié)點，同時保證批量APP與主節(jié)點部署在同一APP。如下圖所示。

圖 TDSQL帶WATCH節(jié)點的部署模式

WATCH節(jié)點與主節(jié)點同IDC部署，從主節(jié)點異步同步數(shù)據(jù)。因為是WATCH節(jié)點是異步同步，所以主節(jié)點的binlog會確保同步到跨IDC的另外兩個備節(jié)點事務才算成功，這樣即使主節(jié)點所在的IDC整個宕掉，仍能保證數(shù)據(jù)的完整性，不會影響IDC容災特性。當主節(jié)點發(fā)生故障時，scheduler模塊對對比watch節(jié)點和其他2個強同步備機的數(shù)據(jù)一致性，如果發(fā)現(xiàn)watch節(jié)點的數(shù)據(jù)跟另外2個idc數(shù)據(jù)一樣新（這是常態(tài)，因為同IDC一般都比跨IDC快），則優(yōu)先會將這個watch節(jié)點提升為主機。這就保證了批量APP與數(shù)據(jù)庫主節(jié)節(jié)點盡量處于同一個IDC，避免了跨IDC訪問帶來的時延影響。

通過以上部署架構，我們實現(xiàn)了同城跨IDC級別的高可用，以及同城跨IDC的應用多活，極大提升了微眾銀行基礎架構的整體可用性與可靠性。

六、TDSQL集群規(guī)模

微眾銀行成立4年多以來，業(yè)務迅速發(fā)展，目前 有效客戶數(shù)已過億級，微粒貸，微業(yè)貸等也成為行業(yè)的明星產(chǎn)品。在業(yè)務規(guī)模迅速增長的過程中，我們的數(shù)據(jù)庫規(guī)模也在不斷的增長。當前微眾銀行的TDSQL SET個數(shù)已達350+（生產(chǎn)+容災），數(shù)據(jù)庫實例個數(shù)已達到1700+，整體 數(shù)據(jù)規(guī)模已達到PB級，承載了微眾銀行數(shù)百個核心系統(tǒng)。在以往的業(yè)務高峰中，最高達到日3.6億+的金融交易量，最高的TPS也達到了10萬+，如下圖所示。

圖 微眾銀行TDSQL業(yè)務規(guī)模

在過去4年多的運營中，TDSQL也從未出現(xiàn)過大的系統(tǒng)故障，或者數(shù)據(jù)安全問題，同時基于TDSQL的X86的軟硬件架構，幫助微眾銀行極大的降低IT戶均成本，極大提升了微眾銀行的行業(yè)競爭力。 微眾銀行通過實踐證明，TDSQL作為金融級的核心數(shù)據(jù)庫，是完全勝任的。

七、微眾銀行數(shù)據(jù)庫現(xiàn)狀及未來發(fā)

目前，TDSQL承載了微眾銀行99%以上線上數(shù)據(jù)庫業(yè)務，同時我行也大量采用了redis作為緩存，以解決秒殺，搶購等熱點場景，另外還有少量的MongoDB滿足文檔類的存儲需求。同時我行從去年開始，也嘗試引入了NEWSQL數(shù)據(jù)庫TiDB，解決少部分無法拆分DCN，但同時又對單庫存儲容量或吞吐量有超大需求的業(yè)務場景。整體來看，我行目前的數(shù)據(jù)庫主要有TDSQL，TIDB以及Redis/MongoDB，TDSQL主要承載核心系統(tǒng)業(yè)務，TIDB作為補充解決單庫需要超大容量或超大吞吐量的非聯(lián)機業(yè)務需求，Reids和MongoDB則主要是提供緩存及文檔型的存儲。當然我們并不會止步于此，微眾銀行數(shù)據(jù)庫團隊和騰訊云TDSQL團隊未來會有更加深入的合作。比如我們和騰訊云TDSQL團隊合作的TDSQL智能運維-扁鵲項目，目前已在微眾銀行灰度上線，可以實時分析TDSQL的運行狀態(tài)和性能問題，是提升運維效率的利器。我們和也在和TDSQL研發(fā)團隊共同調研和評估MySQL 8.0版本，以及MySQL基于MGR的高可用功能，未來可能會嘗試將MySQL 8.0和MGR集成到TDSQL系統(tǒng)中，并嘗試在銀行核心系統(tǒng)中試用。

作者簡介

胡盼盼，微眾銀行數(shù)據(jù)庫平臺負責人。碩士畢業(yè)于華中科技大學，畢業(yè)后加入騰訊，任高級工程師，從事分布式存儲與云數(shù)據(jù)庫相關的研發(fā)與運營工作；2014 年加入微眾銀行，負責微眾銀行的數(shù)據(jù)庫平臺的設計規(guī)劃和運營管理。

黃德志，微眾銀行數(shù)據(jù)庫平臺高級 DBA。2009年加入平安科技，先后擔任數(shù)據(jù)庫資深開發(fā)工程師及資深運維工程師。2016年加入微眾銀行任高級DBA，負責TDSQL相關運維工作。

推薦閱讀

AI調參首次全面超越數(shù)據(jù)庫專家