TiDB 作為一款高效穩定的開源分布式數據庫，在國內外的銀行、證券、保險、在線支付和金融科技行業得到了普遍應用，并在約 20 多種不同的金融業務場景中支撐著用戶的關鍵計算。本篇文章將為大家介紹分布式關系型數據庫 TiDB 在金融行業關鍵應用領域的實踐。

?

金融關鍵業務場景

?

銀行的業務系統非常復雜，包括從核心上的賬戶、賬務、結算等業務到外圍的各種存、貸、票、匯以及面向互聯網場景的各類金融業務。

隨著科技的發展，整個銀行的核心交易系統走在自己的一個演進道路上，從傳統的集中式應用結構逐步向服務化、分布式這樣的體系在演進。在國內，已經有若干家在科技方面比較領先的銀行機構啟動了對于核心的改造工作，在他們整個核心交易應用以及背后的數據處理層引入了非常多分布式的技術來支撐他們業務的發展。在未來，整個發展方向會更多的向單元化、服務化發展，并且一些應用支撐的框架，例如云、微服務、未來的 serverless 等，都會逐漸的向核心交易引入。

分布式核心系統架構對整個數據庫有以下幾點比較明確的要求：

• 安全，穩定，可靠；

• 提供分布式計算與分布式數據管理及在線彈性擴展能力；

• 提供高并發，低延遲，大吞吐的數據庫處理能力；

• 支持聯機交易及批量(日間/終) 批量混合負載；

• 支持核心上的報表和數據報送業務負載；

• 提供可靠和高性能的分布式聯機交易事務；?

• 需要支持至少達到 “兩地三中心” 的雙中心多活及多中心容災保障能力；

• RPO = 0, ?RTO 要達到監管及銀行科技部門對核心系統的高可用要求；

• 核心業務應用開發/改造難度低；

• 完善與便捷的運維管理能力。

?

現有架構痛點

?

目前，很多銀行采用的核心系統數據庫方案主要為傳統的集中式數據庫架構和基于 MySQL 的分庫分表方案，但無論是集中式數據庫架構，還是基于 MySQL 的分布式數據庫架構，都會存在一些問題。集中式數據庫架構主要有以下幾點問題：

• 嚴重依賴專有高端硬件；

• 無法彈性橫向擴展；

• 與新一代分布式服務化核心應用架構匹配度低；

• 建設及維護成本高昂；

• DB2 / Oracle 數據庫技術鎖定；

• 無法利用云計算體系發展成果。

基于 MySQL 的分布式數據庫架構也存在以下幾點問題：

• 數據庫分布式中間件成熟度與可靠性仍需要考驗；

• 應用侵入程度高，改造復雜度大；

• 應用模型和數據模型的鎖定，犧牲靈活性；

• 批量負載處理能力限制；

• 分布式事務能力低下，需要人為應用開發側和規劃側深度規避；

• 強一致性保障的風險；

• 缺乏彈性擴展能力和在線擴展自動平衡的能力；

• MySQL 高可用技術的風險；

• 兩地三中心同城多活復雜度。

?

基于 TiDB? HTAP 架構的銀行核心數據庫解決方案

?

方案一：TiDB 核心交易系統支撐架構

?

第一個是比較直截了當的方案，以 TiDB 作為核心交易庫的主庫。

在這種方式下，整個 TiDB 近似傳統單機集中式數據庫的訪問模式與業務應用開發模式，對應用的訪問是透明的。同時，無論是應用模型、數據模型還是整個事務交易模型，不需要做人為的切分。因為在核心交易應用的發展過程中，除了以賬戶為角度，我們還會以用戶視圖為角度，因此簡單的通過找到用戶的賬戶分片去做切分的話，實際上是犧牲了整個核心交易的靈活性。

另外以 TiDB 作為主庫，內置的多中心、多活容災的機制也簡化了部署的復雜性、管理復雜性和成本；并且完全的分布式聯機交易事務支持，不需要應用干預和提前鎖定事務處理規劃，用戶基本上在 TiDB 上做聯機交易的過程當中，跟單機數據庫的使用是一樣的；另外 TiDB 在后臺提供了一個動態的調度機制，所以在線的進行節點的擴容，完全不會影響業務，無論是后臺數據平衡，還是內部引擎之間的負載均衡的自動分配，都是在引擎內部自己做的，不需要用戶在應用側有特別多的關注。

以 TiDB 作為核心交易庫的主庫，主要有以下幾點價值：

• 在核心系統數據庫側分布式改造大幅度降低改造難度與風險；

• 業務模型和數據模型無需反向適配數據庫架構；

• 透明的計算和數據管理分布式，降低維護復雜度與成本；

• 吞吐量及性能可以隨在線橫向透明擴展；

• 標準 SQL, 分布式事務，多表復雜關聯計算，聯機與批量混合負載處理能力，保障業務靈活性及適配分布式核心應用；

• 內核支持強一致數據部分機制及高可用機制 (RPO=0,RTO <30s）；

• 內核支持多中心多活容災機制。

?

長亮核心交易系統測試

?

我們與城商行一級的系統做了比較完整的對接，包括長亮科技，我們在他的核心交易系統上，包括賬戶、賬務、貸款、發卡、現金管理、資產負載等這些核心模塊做了充分的適配。

長亮核心交易系統關鍵交易壓測成績

從功能、正確性、交易的性能等方面做了充分的適配和優化，完成了 2000 多個核心交易的功能測試，包括全量的近 200 個批處理測試。接下來，我們正在跟長亮科技計劃進行 V8 版本對接測試和基于 ARM 國產化平臺的測試。

?

方案二：核心交易 MySQL + TiDB 后置庫方案

?

第二種方案是以 TiDB 作為整個核心交易的后置庫方案。

?

架構如上圖所示，整個核心交易的應用側根據應用邏輯做一個拆分，這也是現在新一代核心應用結構的演進趨勢。

用戶在核心聯機交易庫使用 MySQL + 中間件的方式來承擔聯機交易的前置庫，在這上面完成最基本的聯機交易，然后通過 TiDB 提供的 CDC 同步工具做準實時的同步，解析 MySQL 分片對的 binlog，并通過自動合庫的方式匯聚到 TiDB 的分布式集群上面。

在 TiDB 分布式集群上可以克服原來由單一的 MySQL Sharding 方案帶來的一些限制，比如前面提到的復雜計算、復雜的實時查詢業務，這些業務負載就可以從聯機交易主庫下線到 TiDB 后置庫上進行完成。這樣可以說是揚長避短，在整個方案當中能夠將整個交易的聯機部分、批量部分、實時查詢部分和復雜的報表部分做一個區分。

?

方案三：

核心交易 MySQL(業務單元化)?+ TiDB 后置庫方案

?

第三種方案和第二種方案類似，但隨著核心交易技術以及架構路線的發展，有不少的解決方案會在核心交易的應用側進行應用維度的微服務化或者單元化的改造。

?

在整個核心交易當中，把交易鏈路上都會用到的客戶中心、產品中心、核算中心與整個交易分離，將這部分單獨拎出來；對于聯機交易和賬戶這部分，例如存款系統與貸款系統，通過業務邏輯上的切分，把他們切分成獨立的單元，可以理解為虛擬的分行系統，通過這種方式在應用的業務層實現橫向的擴展；同時在整個交易鏈路上，例如公共服務中心，可以通過微服務方式抽取出來，在不同模塊之間通過標準接口來作為調用的公共服務區。

這樣的結構產生后，一定會產生多個數據庫對應聯機交易庫。作為業務單元化架構下核心交易聯機庫背后的后置庫，TiDB 同樣可以通過 CDC，將諸如客戶中心、產品中心、核算中心等統一全局維度的庫進行一比一的入庫。同時，對于在應用層已經不是依靠 MySQL 分庫分表，而是靠應用層切割的垂直分庫，能夠通過 CDC 工具直接在 TiDB 層匯聚成一個全局的匯總庫，在這個匯總庫上我們可以完成跨服務單元數據后臺的批量操作，包括復雜查詢以及報表類的業務；同時，又可以保證在整個業務當中，原來共享服務的庫仍舊是以邏輯單獨庫的形態在 TiDB 的大集群當中存在，對業務提供服務。

?

微眾銀行新一代核心系統架構

?

微眾銀行就采用了這種方案作為核心系統架構。微眾銀行在國內的核心交易業務單元化方面有自己的創新之處，在過去三四年的發展過程中，他們整體的核心交易采用了 DCN 的分布式可擴展框架，在應用層實現了擴展性，同時在數據庫層的數據處理界面上又保證了非常好的簡潔性。

DCN 是一個邏輯區域概念，可以等效認為是一個獨立的分支機構，例如一個銀行的分行或者網點，通過 DCN 的橫向擴展來解決業務的擴張問題。他們同樣也采用了以 MySQL 分庫分表為后臺的聯機庫，并將交易和核算分離，通過分布式數據庫 NewSQL 的技術，將批量和核算通過后置庫的方式移到分布式集群當中。

?

TiDB 作為核心交易后置庫的價值

?

TiDB 作為核心交易后置庫的價值主要有以下幾點：

• 解決 MySQL 分布式方案中數據匯總計算處理的挑戰。

• 標準 SQL，分布式事務，多表復雜關聯計算能力提供了跨節點海量數據的高性能批量處理能力。

• HTAP 架構提供行列混合計算能力，海量數據的高性能實時計算。

• 提供完整工具，實現全量同步聯機庫集群數據，隨時成為聯機庫集群的備選切換保障。

• 吞吐量及性能可以隨在線橫向透明擴展。

• 內核支持強一致數據部分機制及高可用機制 (RPO=0,RTO <30s）。

• 內核支持多中心多活容災機制。

?

TiDB 對核心交易場景的潛在價值

?

TiDB 為核心交易場景也帶來了一些潛在價值。

首先我們堅信云一定是未來，TiDB 云原生架構及產品能力(K8s 容器集群)就緒，為上云(私有云)提供了技術基礎。同時，我們在最近已經完成了對商業云基礎平臺 ( 開源 OpenShift、開源 Rancher ）的對接適配，加上 TiDB 基于云資源調度和數據庫本身的調度機制，能夠比較好的實現云中數據庫多租戶的支持能力。

在內核上，TiDB HTAP 行列混合架構能夠支撐未來更多的在線新業務場景，拓寬業務適用面；同時，我們的產品團隊也在跟包括 Flink 的團隊合作，完成了包括流處理的方案適配，為實時處理類業務提供動力。

另外，我們也初步完成了跨數據中心的調度能力，實現多中心間數據感知調度。在多中心的架構下，通過 TiDB 的分布式調度機制與行級數據調度能力，將數據與中心站點進行動態關聯，以地理位置為依據關聯數據表(行集合)，減少跨地域訪問，降低查詢延遲，提高應用的整體性能。同時，利用這樣的核心手段，我們可以對冷熱數據進行比較靈活的調度，對冷熱數據進行分離。

?

解決方案的優勢分析

?

對于核心聯機交易，從傳統方案到 MySQL 的分布式方案，再到以 TiDB 為主庫的方案或者是作為后置庫的方案，TiDB 無論從交易的性能、吞吐、匯總、擴展各方面都有比較顯著的優勢。并且，相比傳統的結構，引入 TiDB 以后在整體硬件、軟件，包括整個運維部署的成本方面都有明顯的優勢。

?

接下來，我們將主要分享 TiDB 在核心外圍的關鍵業務場景的實踐。

?

TiDB 在支付業務中的實踐

?

我們在核心外圍的關鍵業務場景也有很多的案例，例如現在比較典型的在線支付業務。TiDB 主要涉足的支付領域包括商業銀行的網聯/銀聯支付業務的聯機交易數據庫，第三方支付公司的移動支業務核心支付系統。通過 TiDB 提供的大規模吞吐，高性能大并發聯機交易，多中心多活容災，彈性擴展機制來支撐：

• 商業銀行側，來自網聯/銀聯無卡的大并發支付交易指令和支付報文數據處理；

• 第三方支付側，來自移動支付 App，?商戶移動 POS，支付場景嵌入式的支付業務系統后臺的交易指令和支付報文處理；

• 支付交易的聯機處理類，主要為支付錢包數據的處理，支付交易數據聯機插入與更新，交易狀態實時查詢，交易歷史記錄和賬單查詢；

• 支付交易中的費率等計算；

• 支付過程中的反洗錢系統的數據匯聚及規則計算。

自 2018 年投產以來，三年的時間里 TiDB 穩定的支持了北京銀行的網聯支付和銀聯無卡支付的核心系統，采用了北京同城+西安兩地三中心的多活容災結構，順利的渡過了兩次雙十一，比較好的支撐這個業務。另外，我們在包括天翼支付的支付結算、賬單、反洗錢平臺，寶付的支付數據匯聚和日本排名第一的支付公司 PayPay 的聯機支付核心及支付錢包核心平臺，都有了具體的落地案例。

?

TiDB 在互聯網理財業務中的實踐

?

TiDB 主要落地股份制商業銀行財富管理業務條線中的在線理財業務，通過 TiDB 提供的大規模吞吐、高性能大并發聯機交易、多中心多活容災以及彈性擴展機制來支撐理財業務中的：

• 理財交易的聯機事務交易核心處理；

• 理財交易系統的日間及日終的數據批量計算；

• 理財交易系統數據的批量計算輸出到監管報送，數倉等下游業務系統；

• 兩中心多活容災部署，提供高等級業務連續性保障。

今年上半年，我們和光大銀行完成了理財交易核心庫和聯機批庫交易的投產工作，比較好的支撐了整個光大銀行理財業務的核心聯機交易的處理以及日間和日終的數據批量計算。此外，我們也在北京銀行的理財銷售平臺和微眾銀行企業同業的理財交易流水有了相關的場景落地。

?

TiDB 在實時風控業務中的實踐

?

我們還有一大類關鍵的金融應用場景是實時風控業務。跟傳統的風控不一樣，隨著互聯網化的業務場景增多，銀行和泛金融機構對于實時風控的要求是非常高的。TiDB 目前在風控業務中的實時風控數據匯聚、存儲、管理、加工、計算場景方面已經有多個落地實踐。通過 TiDB 分布式存儲核心機制，應對海量數據的實時寫入，同時分布式計算層以及行列混合引擎的設計能夠針對風控指標的點查計算和批量匯總統計計算提供實時處理能力，將傳統基于大數據手段的 “T+1” 風控業務處理能力直接提升到 “T+0” 級別，如高達秒級的風控數據計算查詢。

在金融業務場景方面，我們有包括北京銀行線上業務風控模型管理平臺、微眾銀行 CNC 反欺詐系統、天翼支付反洗錢平臺、拉卡拉金融實時風控平臺等一系列的場景落地。同時在互聯網及電商業務場景中，包括像東南亞知名電商 Shopee 的風控平臺，小紅書反欺詐系統及實時風控平臺、拼多多風控平臺等都有了一些落地。

?

TiDB 保險行業典型場景

?

除了銀行業務之外，TiDB 也廣泛應用在保險行業。在保險行業，主要在前臺、中臺、后臺三大領域有投產業務。

在前臺，主要是偏向于互聯網和移動端聯機交易這一側，包括保單的投保、財富增值、會員活動等一些在線聯機交易的支撐。我們在去年成功的支持了平安產險暖寶保的業務，在很短的時間內完成了整個集群的投產上線以及平安財神節的一個高峰交易。

在中臺，業務主要涉及到以中臺業務群為前端的后臺的數據支撐，包括像中臺的微服務化、單元模塊改造和業務的改造工作，TiDB 能夠通過云原生的架構比較好的適配微服務的應用環境，消除應用對分布式數據存取框架的依賴，無需引入數據中間件，并且能夠做到在線彈性擴展。我們在平安人壽的“金管家”業務和平安產險的“詢價出單”業務中都有相關的落地。

在后臺，由于 TiDB 本身超大規模的海量數據存儲架構以及具備批量數據的處理能力，我們在認證、支付、結算、包括前面提到的風控類業務，都有若干的案例落地。在這類業務中，比較偏向于實時的 OLAP 分析，涉及到 TiDB 提供多種上游數據源匯聚方案。

?

如何從原有架構遷移到 TiDB

?

從金融行業，傳統的業務遷移到 TiDB，有幾點想跟大家分享一下。

TiDB 的整體架構是多中心的結構，尤其是對于核心交易和關鍵業務場景來說，這個是剛需。我們也是在包括北京銀行、光大銀行的兩個核心交易庫上面實現了多中心的架構。

?

TiDB 核心交易系統遷移投產規劃管理

?

因為涉及到整個金融機構里非常重要并且關鍵的系統，核心交易系統 TiDB 投產的技術原則是處處有核驗，步步可回退。有以下幾種投產策略可以供大家參考。

第一種策略是雙寫策略。通過在應用側實現一個雙寫路由，來對傳統組庫、交易組庫和對 TiDB 作為一個集群的鏡像庫做雙路的轉發。它的優點就是控制顆粒非常精細，TiDB 無論從時間維度還是交易的負載維度上，都得到了全部的交易負載和特征，割接窗口短投入。但需要構造雙寫路由機制以及數據校驗的機制，當然我們也有一些工具和技術手段可以提供。

第二種策略就是作為主從級別方式來進行投產和遷移。交易組庫，例如 Oracle，繼續承擔所有交易組庫的讀寫流量。TiDB 通過 Golden Gate 等專業的第三方工具，可以非常方便的去捕獲到 Oracle 整個數據全量和增量的實時變化。這個策略的優點是投產周期非常短，整個業務的改造工作量非常低。但也需要做一些額外的工作，首先是需要做更加細致的數據校驗，因為是通過主從的結構來獲得數據的一些變化；另外，當主從校驗中，如果發現有數據問題，那在割接前需要通過技術手段進行修正。當然，我們有一些相關校驗和修整的技術手段，能夠在割接、交付、投產之前幫助用戶去做校驗和修整的機制。

第三種策略是直接把 TiDB 作為主庫，把傳統的庫作為托底方案。這個方案是借助于我們與國內主要的數據庫頭部方案廠商迪思杰(DSG)在產品上面的一個完整適配。現在 TiDB 能夠基于 DSG 把 Oracle 系統作為托底的一個集群。這個策略的優點是投產迅速，有托底保障，但也需要構造數據校驗及修正手段，整體回退時間較長。

最后一個策略是做一個灰度，通過交易模塊的切分，按照模塊的邊界來把一部分的交易承擔在主庫上，另一部分的交易放在 TiDB 上。這個策略的好處是灰度按照業務模塊遷移，對整個業務的整體的風險有比較好的把控，但可能需要需要更加復雜的應用模塊級細分遷移方案和配套工具。

?

數據備份恢復保障

?

去年我們實現了關于存儲引擎層的物理層的分布式備份的方案，叫做 BR(Backup & Restore)。BR 能夠實現在數量固定的情況下，節點越多，備份速度越快，實現了一個在非邏輯層和物理層的備份。

除了 TiDB 原生的兩地三中心的 Raft based 方案外，去年我們也在產品當中完成了兩中心強一致的備份方案。因為一些銀行機構或者金融機構的業務中，可能不需要兩地三中心，只需要兩中心的災備容災方案就足夠了。我們在 Raft 的框架上面，實現了兩中心的強一致的方案，適配同城及近距離異地中心，且中心間通信延遲較好場景，能夠實現金融級的 RPO=0 的要求。

總結

以上是生活随笔為你收集整理的TiDB 在金融关键业务场景的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。