分布式數(shù)據(jù)庫在金融核心的應(yīng)用實踐

1、分布式數(shù)據(jù)庫在金融核心的應(yīng)用實踐技術(shù)創(chuàng)新，變革未來2020金融行業(yè)現(xiàn)狀目前國內(nèi)大中型銀行主要以國外廠商提供的大型主機(jī)和數(shù)據(jù)庫解決方 案來進(jìn)行系統(tǒng)構(gòu)建。由于近年來金融業(yè)務(wù)量的不斷增長，以及銀行數(shù) 字化轉(zhuǎn)型成為必然趨勢。目前以國外大型主機(jī)和數(shù)據(jù)庫為核心的架構(gòu) 已無法滿足大規(guī)模交易和數(shù)據(jù)處理的需求。一方面：性能無法滿足業(yè)務(wù)不斷激增的處理需求，存在系統(tǒng)過載風(fēng)險； 另一方面：本身價格比較昂貴，維護(hù)成本居高不下。以手機(jī)銀行、網(wǎng)上理財、互聯(lián)網(wǎng)保險等為代表的金融業(yè)務(wù)創(chuàng)新 快速發(fā)展，推動新技術(shù)正以前所未有的速度與力度發(fā)生深層次 變革。這些技術(shù)發(fā)展，對金融服務(wù)模式帶來重大影響，使得金融行業(yè) 向數(shù)字化、分布式轉(zhuǎn)型成

2、為必然趨勢，金融業(yè)務(wù)創(chuàng)新與科技創(chuàng) 新正在相互促進(jìn)，重塑金融行業(yè)系統(tǒng)能力。微信支付圖webank微粒貸微車貸金融行業(yè)現(xiàn)狀2020多種架構(gòu)長期共存Shared-Nothing&Shared-storge多種技術(shù)棧卡位競爭 兼容MySQL&Oracle&PG廠商的互相PKDBDBDBDBDiskDiskDiskDisk負(fù)載均衡器DB Engine (master)CynosFSBlock APIDB Engine (slave)CynosFSBlock APIDB Engine (slave)CynosFSBlock APISeg SegStorage ServiceSeg SegSeg SegSt

3、orage ServiceSeg SegSeg SegStorage ServiceSeg SegRWROROContinuous BackupCold Backup StorageWallog Sync Wallog Sync storage cluster managerdb instance managerPool分布式數(shù)據(jù)庫領(lǐng)域的百家爭鳴2020質(zhì)量可靠團(tuán)隊建設(shè)持續(xù)演進(jìn)服務(wù)能力建立能用， 會用， 用好國產(chǎn)數(shù) 據(jù)庫的人才隊伍； 形成一支具 備高水平維護(hù)能力的隊伍。在國內(nèi)主要地市建立健全分銷 體系、培訓(xùn)能力、服務(wù)團(tuán)隊。 不僅包括數(shù)據(jù)庫， 更能覆蓋金 融全技術(shù)棧的服務(wù)能力。背靠優(yōu)質(zhì)平臺或生態(tài)

4、， 產(chǎn)品可 以持續(xù)演進(jìn)發(fā)展； 廠商擁有一 流的研發(fā)團(tuán)隊和長期投入。02金融客戶應(yīng)該如何選擇分布式數(shù)據(jù)庫2020010403產(chǎn)品應(yīng)該成熟可靠， 經(jīng)過大規(guī) 模業(yè)務(wù)持續(xù)驗證， 擁有較多的 客戶案例和I S V 集成經(jīng)歷。騰訊云分布式數(shù)據(jù)庫解決方案2020 自有業(yè)務(wù)打磨 產(chǎn)研結(jié)合 產(chǎn)用結(jié)合TDSQL TBASETencent Cloud Enterprise月活用戶達(dá)10.82億交易筆數(shù)超過4600億筆7000萬微粒預(yù)授信3800萬開通用戶6000億累計放款額200億賬戶（含合作伙伴）500億+日均請求 平均5毫秒響應(yīng)微信支付圖微粒微2020金融應(yīng)用實踐金融客戶主機(jī)下移引起的思考其他典型場景分布式數(shù)據(jù)

5、庫如何適配分析與恢復(fù)事務(wù)實時強(qiáng)一致數(shù)據(jù)冷熱分布數(shù)據(jù)彈性如何選擇分布式技術(shù)棧如何設(shè)計信息技術(shù)創(chuàng)新節(jié)奏 如何使用分布式數(shù)據(jù)庫新老系統(tǒng)的切換分布式的擴(kuò)展容災(zāi)方案如何對國產(chǎn)數(shù)據(jù)庫進(jìn)行運(yùn)維2020分布式技術(shù)棧的選擇：對主流方向都有布局和應(yīng)用2020微信支付等“互聯(lián)網(wǎng)”通用方案：已經(jīng)形成可鋪開的經(jīng)驗和方法論（書籍、文檔或代碼等） 已有大量的應(yīng)用代碼、SQL改造案例成熟的數(shù)據(jù)遷移、同步工具社區(qū)、高校、培訓(xùn)機(jī)構(gòu)大量相關(guān)課 程?；ヂ?lián)網(wǎng)廠商十余年來的人才輸出。微信支付商戶系統(tǒng)的“互聯(lián)網(wǎng)”通用 方案；常見于基于PostgreSQL或國內(nèi) 自研Oracle兼容類數(shù)據(jù)庫，HTAP數(shù)據(jù) 庫等復(fù)用Oracle現(xiàn)有SQL，一

6、定程度降低ISV改造成本。復(fù)用PostgreSQL社區(qū)的經(jīng)驗和方法論。數(shù)據(jù)遷移、同步相對方案簡單。成熟分布式技術(shù)棧易于團(tuán)隊建設(shè)降低遷移門檻降低改造成本典型產(chǎn)品：騰訊TDSQL（MySQL技術(shù)棧），騰訊TBase（Oracle兼容技術(shù)棧）MySQLOracle兼容五年計劃原則： 建立一支熟悉分布式數(shù)據(jù)庫技術(shù)棧的技術(shù)團(tuán)隊。根據(jù)業(yè)務(wù)重要性， 分批分階段改造業(yè)務(wù)系統(tǒng)。技術(shù)方案應(yīng)在不影響宏觀穩(wěn)定， 確保業(yè)務(wù)與數(shù)據(jù)庫磨合。該技術(shù)應(yīng)該是可以復(fù)用或容易建立的。應(yīng)該是在完全磨合好以后， 再全量切換。技術(shù)團(tuán)隊分批 改造業(yè)務(wù)磨合技術(shù) 復(fù)用全量切換20182019 團(tuán)隊招聘與培養(yǎng)20202020（試點）核心系統(tǒng)改造2

7、0212022最終核心交易全量切換確定基于oracle+MySQL實現(xiàn)雙技術(shù)棧團(tuán)隊建設(shè)，并選擇互聯(lián)網(wǎng)銀行業(yè)務(wù)選 擇開源MySQL方案打磨團(tuán)隊。 團(tuán)隊對MySQL熟悉后，實現(xiàn)核心業(yè)務(wù)系統(tǒng)基于騰訊云TDSQL上線并開始運(yùn)營新老系統(tǒng)并行 剩余系統(tǒng)改造老業(yè)務(wù)系統(tǒng)不下線，數(shù)據(jù)保證實施同 步回老業(yè)務(wù)系統(tǒng)，如果新業(yè)務(wù)系統(tǒng)一 旦故障確保老系統(tǒng)可用。在運(yùn)行一段時間后，確保新系統(tǒng)完全 穩(wěn)定后，再封存老系統(tǒng)。技術(shù)創(chuàng)新節(jié)奏：某大型銀行客戶的主機(jī)下移“五年計劃”化，問題攻堅監(jiān)管機(jī)構(gòu)專家評審2018.4-2018.5選型進(jìn)行POC測試2018.5對騰訊TDSQL進(jìn)行深入測試2018.6-2018.7進(jìn)一步探討分布式數(shù)據(jù)庫

8、的落地方案2018.8-2018.10中間業(yè)務(wù)系統(tǒng)及ECIF系統(tǒng) TDSQL配套改造并完成上 線2018.10-2019.1新核心適配性改造及 TDSQL優(yōu)化升級和功能增 強(qiáng)2019.1-2019.7成立攻堅小組，進(jìn)行深入的驗證，業(yè)務(wù)優(yōu)2019.42019.5監(jiān)管機(jī)構(gòu)驗證匯報，現(xiàn) 場驗收，得到省聯(lián)社認(rèn) 可2019.5決定使用TDSQL投產(chǎn)2019.5-2019.6擴(kuò)大壓測范圍， 至500個交易2019.7生產(chǎn)機(jī)器性能論證2019.8項目投產(chǎn)初步驗證可行性2020驗證系統(tǒng)適配性全面驗證2019.5-2019.6對集中式版本進(jìn) 行2輪專題測試技術(shù)創(chuàng)新節(jié)奏：某銀行客戶傳統(tǒng)核心業(yè)務(wù)系統(tǒng)改造過程數(shù)據(jù)層下

9、移的拆分策略：水平拆分&垂直拆分SOA時代，按業(yè)務(wù)維度垂直拆分2020分布式改造 數(shù)據(jù)水平拆分不是所有都需 要進(jìn)行分布式 改造！拆分方案通常分為按客戶維度拆分按分公司（法人）維度拆分按時間維度拆分其他數(shù)據(jù)層下移的拆分策略：水平拆分的主要方案2020直觀需求為數(shù)據(jù)： 1TB單表： 千萬級并發(fā)： 10K/s通用性 容量伸縮數(shù)據(jù)分片-1數(shù)據(jù)分片-1數(shù)據(jù)分片-n業(yè)務(wù)模塊數(shù)據(jù)水平拆分策略：按客戶維度進(jìn)行拆分2020p n邏輯表物理表p 0p 1p2hashp 3數(shù)據(jù)特點客戶規(guī)模較大客戶無明顯分布性單筆交易金額小、筆數(shù)多常見對私業(yè)務(wù)數(shù)據(jù)層水平拆分策略：按分公司（法人）維度進(jìn)行拆分2020分公司1分公司3業(yè)

10、務(wù)模塊分公司2SET-1分公司4SET-2分公司1 分片a分公司1 分片b分公司1 分片c數(shù)據(jù)特點業(yè)務(wù)按分公司維度開展。交易/清算等以該維度展開不同分公司交易規(guī)模區(qū)別明顯總部搭建業(yè)務(wù)系統(tǒng)和數(shù)據(jù)收口分公司總數(shù)少，但交易數(shù)量多分公司5分公司6SET-3vSET-1vSET-3分公司2 分片a分公司2 分片b分公司1 分片cvSET-2Group-SET-1vSET-1vSET-2Group-SET-2vSET-3Group-SET-3分布式計算層分布式計算層分布式計算層業(yè)務(wù)模塊常規(guī)方案騰訊方案數(shù)據(jù)層下移的拆分策略：按時間維度進(jìn)行拆分2020歷史庫DTS業(yè)務(wù)模塊分布式計算層分布式計算層分布式計算層二

11、級拆分 基于時間一級拆分?jǐn)?shù)據(jù)特點業(yè)務(wù)按時間（年/月）分布不同時間區(qū)間交易規(guī)模差異較大（如京東618）歷史數(shù)據(jù)規(guī)律性搬遷/刪除常見于訂單類業(yè)務(wù)分析庫大數(shù)據(jù)第三方系統(tǒng)遷移需求 溝通遷移開發(fā)& 測試遷移實施資源準(zhǔn)備服務(wù)交割客戶架構(gòu)師 或ISV：騰訊技術(shù)人員：方案評審結(jié)果確認(rèn) 完全切割騰訊云數(shù)據(jù)庫應(yīng)用遷移服務(wù)商用數(shù)據(jù)庫騰訊分布式工具遷移服務(wù)評估工具數(shù)據(jù)遷移工具數(shù)據(jù)驗證工具數(shù)據(jù)驗證工具遷移評估 方案設(shè)計 改造建議 優(yōu)化建議新老系統(tǒng)的切換：DTS-DBBridge2020遷移評估 報告新老同步或 雙寫助力用戶現(xiàn)場保障實例概覽，宏觀把握全局全實例監(jiān)控，輕松發(fā)現(xiàn)隱患幫助用戶快速恢復(fù)業(yè)務(wù)7*24實時異常診斷SQ

12、L限流提供快速降級國產(chǎn)數(shù)據(jù)庫的運(yùn)維：DBBrain&分布式數(shù)據(jù)庫管理系統(tǒng)2020分布式多活多SET化擴(kuò)展容災(zāi)方案2020傳統(tǒng)兩地三中心的痛點1、容災(zāi)需要人工干預(yù)2、備機(jī)房常態(tài)下無流量，利用率較低。3、切換時無法確保備機(jī)房100%可靠， 檢查和決策時間長。4、單機(jī)房系統(tǒng)容量有限，A業(yè)務(wù) SET2A業(yè)務(wù) SET4B業(yè)務(wù) SET6IDC 1綜合SET1SET2 DBSET4 DBSET6 DBSET1 DB(主)綜合SET1B業(yè)務(wù) SET7A業(yè)務(wù) SET6IDC 2A業(yè)務(wù) SET6SET1 DB(從)SET4 DBSET6 DBSET1 DB(主)A業(yè)務(wù)B業(yè)務(wù)業(yè)務(wù)網(wǎng)關(guān)業(yè)務(wù)網(wǎng)關(guān)A Relay Prox

13、yB Relay ProxyIDC 3第三方SET1第三方SE2公共SET (主)公共SET (備)強(qiáng)同步SET1 DB(從)數(shù)據(jù)雙向同步典型場景：異常場景的恢復(fù)&全局一致性數(shù)據(jù)分析2020主實例交易系統(tǒng)分析程序分布式事務(wù)補(bǔ)償分析實例恢復(fù)到23:00對賬系統(tǒng)優(yōu)勢：數(shù)據(jù)庫默認(rèn)可回檔到 X天以內(nèi)任意時間；如果對 賬錯誤，可以重新發(fā)起。 劣勢：特殊異常場景下，恢 復(fù)時間可能較長。方案一方案二主實例分析快照交易系統(tǒng)分析程序GTS絕對時間戳 數(shù)據(jù)多版本控制交易數(shù)據(jù)全局一致性快照恢復(fù)到專用分析實例中清算、結(jié) 算系統(tǒng)優(yōu)勢：快照理論上恢復(fù)時 間可控，快照更加精準(zhǔn)。 劣勢：全局一致性快照有 且只有一個，如果遇到

14、對 賬錯誤，需要綜合方案一 處理。分析數(shù)據(jù)分析數(shù)據(jù)對賬系統(tǒng)清算、結(jié) 算系統(tǒng)恢復(fù)的實例即可以用于分析，也可以用于異常情況下快速回退barrierpreparcommit1設(shè)置一致性標(biāo)簽：事務(wù)柵欄A:Balance += 510e15DB1A（transaction barrier）事務(wù)preparcommitB:Balance -= 510e5DB2Bbarrier1事務(wù)A:Balance += 5B:Balance -= 5prepar ecommitprepar ecommitDB1DB21010155AB全局最大一致時間戳：GTS0100200300典型場景：分布式事務(wù)實時強(qiáng)一致2020事

15、件中心小商戶熱group大商戶熱group小商戶冷group大商戶冷group連接池40w+商戶賬單查詢連接池容災(zāi)副本案例特征支持業(yè)務(wù)：商戶交易訂單寫入、實時查詢、訂單 退款等寫入：事件中心通過消息隊列寫入，連接池實現(xiàn)進(jìn)一步連接做連接收斂 查詢：提供商戶查詢訂單事務(wù)：依賴完整事務(wù)特性，數(shù)據(jù)一致性高要 求穩(wěn)定性：2016年上線穩(wěn)定運(yùn)行至今多維度數(shù)據(jù)治理冷熱存儲分離，大小商戶分離容災(zāi)策略采用同城兩中心三副本+周期冷備+WAL實時歸檔典型場景：渠道類業(yè)務(wù)冷熱數(shù)據(jù)不均2020TBL_A(f1-分布列, f2)TBL_B(f1-分布列, f2)select * from tbl_a, tbl_b where tbl_a.f1 = tbl_b.f2;TBL_A.f1 = TBL_B.f2CNDN1TBL_A.f1 = TBL_B.f2DN2TBL_A.f1 = TBL_B.f2DN3TBL_A.f1 = TBL_B.f2節(jié)點級并行典型場景：復(fù)雜SQL處理（跑批等）2020進(jìn) 程 級 并 行典型場景：分布式彈性2020徹底解決數(shù)據(jù)一 致性問題實現(xiàn)自動化運(yùn)維 管理2020節(jié)省大量運(yùn)維成 本業(yè)