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

?

金融關(guān)鍵業(yè)務(wù)場景

?

銀行的業(yè)務(wù)系統(tǒng)非常復(fù)雜，包括從核心上的賬戶、賬務(wù)、結(jié)算等業(yè)務(wù)到外圍的各種存、貸、票、匯以及面向互聯(lián)網(wǎng)場景的各類金融業(yè)務(wù)。

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

分布式核心系統(tǒng)架構(gòu)對整個數(shù)據(jù)庫有以下幾點比較明確的要求：

• 安全，穩(wěn)定，可靠；

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

• 提供高并發(fā)，低延遲，大吞吐的數(shù)據(jù)庫處理能力；

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

• 支持核心上的報表和數(shù)據(jù)報送業(yè)務(wù)負(fù)載；

• 提供可靠和高性能的分布式聯(lián)機交易事務(wù)；?

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

• RPO = 0, ?RTO 要達(dá)到監(jiān)管及銀行科技部門對核心系統(tǒng)的高可用要求；

• 核心業(yè)務(wù)應(yīng)用開發(fā)/改造難度低；

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

?

現(xiàn)有架構(gòu)痛點

?

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

• 嚴(yán)重依賴專有高端硬件；

• 無法彈性橫向擴展；

• 與新一代分布式服務(wù)化核心應(yīng)用架構(gòu)匹配度低；

• 建設(shè)及維護成本高昂；

• DB2 / Oracle 數(shù)據(jù)庫技術(shù)鎖定；

• 無法利用云計算體系發(fā)展成果。

基于 MySQL 的分布式數(shù)據(jù)庫架構(gòu)也存在以下幾點問題：

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

• 應(yīng)用侵入程度高，改造復(fù)雜度大；

• 應(yīng)用模型和數(shù)據(jù)模型的鎖定，犧牲靈活性；

• 批量負(fù)載處理能力限制；

• 分布式事務(wù)能力低下，需要人為應(yīng)用開發(fā)側(cè)和規(guī)劃側(cè)深度規(guī)避；

• 強一致性保障的風(fēng)險；

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

• MySQL 高可用技術(shù)的風(fēng)險；

• 兩地三中心同城多活復(fù)雜度。

?

基于 TiDB? HTAP 架構(gòu)的銀行核心數(shù)據(jù)庫解決方案

?

方案一：TiDB 核心交易系統(tǒng)支撐架構(gòu)

?

第一個是比較直截了當(dāng)?shù)姆桨?#xff0c;以 TiDB 作為核心交易庫的主庫。

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

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

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

• 在核心系統(tǒng)數(shù)據(jù)庫側(cè)分布式改造大幅度降低改造難度與風(fēng)險；

• 業(yè)務(wù)模型和數(shù)據(jù)模型無需反向適配數(shù)據(jù)庫架構(gòu)；

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

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

• 標(biāo)準(zhǔn) SQL, 分布式事務(wù)，多表復(fù)雜關(guān)聯(lián)計算，聯(lián)機與批量混合負(fù)載處理能力，保障業(yè)務(wù)靈活性及適配分布式核心應(yīng)用；

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

• 內(nèi)核支持多中心多活容災(zāi)機制。

?

長亮核心交易系統(tǒng)測試

?

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

長亮核心交易系統(tǒng)關(guān)鍵交易壓測成績

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

?

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

?

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

?

架構(gòu)如上圖所示，整個核心交易的應(yīng)用側(cè)根據(jù)應(yīng)用邏輯做一個拆分，這也是現(xiàn)在新一代核心應(yīng)用結(jié)構(gòu)的演進趨勢。

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

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

?

方案三：

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

?

第三種方案和第二種方案類似，但隨著核心交易技術(shù)以及架構(gòu)路線的發(fā)展，有不少的解決方案會在核心交易的應(yīng)用側(cè)進行應(yīng)用維度的微服務(wù)化或者單元化的改造。

?

在整個核心交易當(dāng)中，把交易鏈路上都會用到的客戶中心、產(chǎn)品中心、核算中心與整個交易分離，將這部分單獨拎出來；對于聯(lián)機交易和賬戶這部分，例如存款系統(tǒng)與貸款系統(tǒng)，通過業(yè)務(wù)邏輯上的切分，把他們切分成獨立的單元，可以理解為虛擬的分行系統(tǒng)，通過這種方式在應(yīng)用的業(yè)務(wù)層實現(xiàn)橫向的擴展；同時在整個交易鏈路上，例如公共服務(wù)中心，可以通過微服務(wù)方式抽取出來，在不同模塊之間通過標(biāo)準(zhǔn)接口來作為調(diào)用的公共服務(wù)區(qū)。

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

?

微眾銀行新一代核心系統(tǒng)架構(gòu)

?

微眾銀行就采用了這種方案作為核心系統(tǒng)架構(gòu)。微眾銀行在國內(nèi)的核心交易業(yè)務(wù)單元化方面有自己的創(chuàng)新之處，在過去三四年的發(fā)展過程中，他們整體的核心交易采用了 DCN 的分布式可擴展框架，在應(yīng)用層實現(xiàn)了擴展性，同時在數(shù)據(jù)庫層的數(shù)據(jù)處理界面上又保證了非常好的簡潔性。

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

?

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

?

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

• 解決 MySQL 分布式方案中數(shù)據(jù)匯總計算處理的挑戰(zhàn)。

• 標(biāo)準(zhǔn) SQL，分布式事務(wù)，多表復(fù)雜關(guān)聯(lián)計算能力提供了跨節(jié)點海量數(shù)據(jù)的高性能批量處理能力。

• HTAP 架構(gòu)提供行列混合計算能力，海量數(shù)據(jù)的高性能實時計算。

• 提供完整工具，實現(xiàn)全量同步聯(lián)機庫集群數(shù)據(jù)，隨時成為聯(lián)機庫集群的備選切換保障。

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

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

• 內(nèi)核支持多中心多活容災(zāi)機制。

?

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

?

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

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

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

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

?

解決方案的優(yōu)勢分析

?

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

?

接下來，我們將主要分享 TiDB 在核心外圍的關(guān)鍵業(yè)務(wù)場景的實踐。

?

TiDB 在支付業(yè)務(wù)中的實踐

?

我們在核心外圍的關(guān)鍵業(yè)務(wù)場景也有很多的案例，例如現(xiàn)在比較典型的在線支付業(yè)務(wù)。TiDB 主要涉足的支付領(lǐng)域包括商業(yè)銀行的網(wǎng)聯(lián)/銀聯(lián)支付業(yè)務(wù)的聯(lián)機交易數(shù)據(jù)庫，第三方支付公司的移動支業(yè)務(wù)核心支付系統(tǒng)。通過 TiDB 提供的大規(guī)模吞吐，高性能大并發(fā)聯(lián)機交易，多中心多活容災(zāi)，彈性擴展機制來支撐：

• 商業(yè)銀行側(cè)，來自網(wǎng)聯(lián)/銀聯(lián)無卡的大并發(fā)支付交易指令和支付報文數(shù)據(jù)處理；

• 第三方支付側(cè)，來自移動支付 App，?商戶移動 POS，支付場景嵌入式的支付業(yè)務(wù)系統(tǒng)后臺的交易指令和支付報文處理；

• 支付交易的聯(lián)機處理類，主要為支付錢包數(shù)據(jù)的處理，支付交易數(shù)據(jù)聯(lián)機插入與更新，交易狀態(tài)實時查詢，交易歷史記錄和賬單查詢；

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

• 支付過程中的反洗錢系統(tǒng)的數(shù)據(jù)匯聚及規(guī)則計算。

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

?

TiDB 在互聯(lián)網(wǎng)理財業(yè)務(wù)中的實踐

?

TiDB 主要落地股份制商業(yè)銀行財富管理業(yè)務(wù)條線中的在線理財業(yè)務(wù)，通過 TiDB 提供的大規(guī)模吞吐、高性能大并發(fā)聯(lián)機交易、多中心多活容災(zāi)以及彈性擴展機制來支撐理財業(yè)務(wù)中的：

• 理財交易的聯(lián)機事務(wù)交易核心處理；

• 理財交易系統(tǒng)的日間及日終的數(shù)據(jù)批量計算；

• 理財交易系統(tǒng)數(shù)據(jù)的批量計算輸出到監(jiān)管報送，數(shù)倉等下游業(yè)務(wù)系統(tǒng)；

• 兩中心多活容災(zāi)部署，提供高等級業(yè)務(wù)連續(xù)性保障。

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

?

TiDB 在實時風(fēng)控業(yè)務(wù)中的實踐

?

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

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

?

TiDB 保險行業(yè)典型場景

?

除了銀行業(yè)務(wù)之外，TiDB 也廣泛應(yīng)用在保險行業(yè)。在保險行業(yè)，主要在前臺、中臺、后臺三大領(lǐng)域有投產(chǎn)業(yè)務(wù)。

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

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

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

?

如何從原有架構(gòu)遷移到 TiDB

?

從金融行業(yè)，傳統(tǒng)的業(yè)務(wù)遷移到 TiDB，有幾點想跟大家分享一下。

TiDB 的整體架構(gòu)是多中心的結(jié)構(gòu)，尤其是對于核心交易和關(guān)鍵業(yè)務(wù)場景來說，這個是剛需。我們也是在包括北京銀行、光大銀行的兩個核心交易庫上面實現(xiàn)了多中心的架構(gòu)。

?

TiDB 核心交易系統(tǒng)遷移投產(chǎn)規(guī)劃管理

?

因為涉及到整個金融機構(gòu)里非常重要并且關(guān)鍵的系統(tǒng)，核心交易系統(tǒng) TiDB 投產(chǎn)的技術(shù)原則是處處有核驗，步步可回退。有以下幾種投產(chǎn)策略可以供大家參考。

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

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

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

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

?

數(shù)據(jù)備份恢復(fù)保障

?

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

除了 TiDB 原生的兩地三中心的 Raft based 方案外，去年我們也在產(chǎn)品當(dāng)中完成了兩中心強一致的備份方案。因為一些銀行機構(gòu)或者金融機構(gòu)的業(yè)務(wù)中，可能不需要兩地三中心，只需要兩中心的災(zāi)備容災(zāi)方案就足夠了。我們在 Raft 的框架上面，實現(xiàn)了兩中心的強一致的方案，適配同城及近距離異地中心，且中心間通信延遲較好場景，能夠?qū)崿F(xiàn)金融級的 RPO=0 的要求。

總結(jié)

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

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