本文是騰訊云TDSQL首席架構師張文在騰訊云Techo開發者大會現場的演講實錄，演講主題是《TDSQL在銀行傳統核心系統中的應用實踐》，
我是TDSQL架構師張文，同時也是TDSQL的開發人員之一，今天的分享內容主要包含四個部分，分別為銀行行業現狀介紹、核心系統分布式改造、TDSQL最佳實踐和改造效果，
張文演講現場
搜索關注“騰訊云資料庫”官方微信，回復“1106張文”即可下載本視頻演講PPT，
一、關于TDSQL
銀行資料庫系統被外企壟斷超過99%，資料庫的復雜程度比擬作業系統，作為基礎性軟體資料庫對成熟度有著極高的要求，這意味著需要較長的研究周期和測驗才可以進入市場，這也是為什么國內商用資料庫領域長期被國外企業所壟斷，
外企資料庫相對收費比較高昂，對于騰訊這種大型互聯網企業，比如說搞個游戲充值活動或者過年的微信紅包，都會產生突增的負載和流量，按照負載來收費，成本將無法估量，所以，如果用傳統的商用資料庫，我們賺的錢可能還不夠買資料庫服務付出的費用，這就倒逼大型互聯網企業研發自己的資料庫，
TDSQL誕生于騰訊計費平臺部，2002年以前計費業務最早使用MySQL就能滿足需求，但是隨著公司規模的發展，到2007年我們對性能、可用性以及資料一致性要求越來越高，同時騰訊的增值業務、娛樂業務在不斷增長，比如Q幣，這時我們開始研制服務于計費、定位于金融場景的分布式資料庫——TDSQL，
2007-2014年，TDSQL在內部通過不斷迭代、踩坑，逐步打磨成了一款比較成熟的資料庫產品，2014年TDSQL首次嘗試對外輸出，成功應用于微眾銀行的核心系統，開始商業化探索，2019年TDSQL成功應用到張家港銀行新核心系統，成為國內第一家投產于銀行傳統核心系統的分布式資料庫，這是TDSQL又一個里程碑式的發展，
二、TDSQL在銀行核心系統的實踐
剛才提到銀行的核心系統，介紹一下什么叫銀行的核心系統，
銀行的核心系統為什么這么重要？銀行的核心系統相當于銀行的心臟，大家知道銀行是要存錢、管錢的，銀行系統分兩部分，一個是核心系統，一個是外圍系統，核心系統可以比作銀行的大腦，所有和錢有關的交易都需要經過核心系統，完成資金的清算核算，換句話說核心系統需要和其他所有關于錢的系統打交道，因而它的業務邏輯也最為復雜、最為關鍵，它直接影響著銀行核心資產相關的資料，如果核心系統比作大腦的話，外圍系統更像是四肢軀干，所以，外圍系統一般都是泛指各類渠道類業務，比如：手機銀行、貸款、柜面、ATM等，而這些外圍系統一旦涉及到金錢交易，必須通過核心系統完成資金的清算結算，一個外圍系統一般都是一個單一的業務場景，所以一個外圍系統故障只影響當前業務，不會影響全域，
此外，銀行對資料庫的可用性要求極高，如果一家銀行長時間不能對外提供服務的話，客戶會對他在銀行中存的錢擔憂，可能會覺得不安全，進而把錢取出來，如果大家都這么做，那么對于銀行來說就是擠兌危機，
- 傳統資料庫架構的分布式改造
下面我們來了解一下如何把銀行的核心系統資料庫從集中式升級成分布式，
在切入正題之前，這里先講一個小故事，在做分布式改造的時候，一開始大家很有信心感覺非常簡單，直接套用即可，進而直接把集中式的系統照搬到分布式，發現效果非常不理想主要表現在性能很差，甚至一些復雜的SQL都跑不出來結果，雖然信心備受打擊，但事情都要邁出第一步，如果什么事情都很容易的話，國內當時為何還遲遲沒有銀行分布式核心資料庫的先例?
對于資料庫從集中式遷移到分布式遇到的問題，首先我們通過對每一個庫表進行分析并重新設計其分片關鍵字，獲取最佳的資料分布策略，從集中式遷移到分布式，多少有一些資料庫高級特效的耦合問題，比如說TDSQL不支持序列，而Oracle支持序列同時業務代碼中用到了大量序列，需要指出的是，TDSQL已經是一款標準化的資料庫產品，但同時TDSQL也非常珍惜在銀行傳統核心系統的實踐機會，因而對于一些行業內比較好的特性建議（比如序列），我們會將其放入迭代特性中開發，
解決了這個語法差異之后，又發現一個問題，由于銀行的核心系統都是運行多年的老系統，這些老系統在早期開發時為了讓業務層更簡單，將很多計算相關的操作也放在了資料庫層，即用到了很多函式、存盤程序、觸發器，在我們內部盡可能不使用這些特性，這些特性不適用于分布式場景下，同時一旦使用后，將來還會面臨復雜的遷移作業，此外，資料庫應該專注于資料存取，計算相關的復雜邏輯放在業務層更符合規范，對這些問題經TDSQL團隊與跟業務方一起溝通評估，將更合適放在應用層的部分邏輯上移，最終實作了更為徹底的分布式架構，
最后是性能問題解決，對于銀行這類金融企業經常會有一些跑批類業務，這類業務的特點是大多都是較為復雜的AP型的SQL，這類SQL對于OLTP型分布式資料庫來說是一個比較大的挑戰，主要體現在資料的存盤方式上，復雜的SQL一般涉及多個表之間的資料，對于集中式所有資料存盤在一個節點上，不存在跨節點取資料，而分布式架構下，資料分散在不同物理節點，一旦涉及多個節點的關聯查詢，會導致性能急劇下降，針對銀行業務的這種AP型場景，TDSQL在復雜SQL處理方面做了一系列優化，如：子查詢上體、左連接消除，豐富下推策略等，盡可能提高處理復雜sql的性能，最后當前述作業做完之后，其實我們已經達到交付標準，對于張家港行來說已經夠用了，但是，畢竟是作為全國第一家投產于傳統核心系統的分布式資料庫，作為第一家就應該有一個第一家的樣子，所以步驟5是一個持續優化的程序，利用TDSQL一系列性能優化、診斷工具，對每一條可優化sql進行優化，最終把性能提升到極致，步驟5結束后，張家港行新核心系統從剛開始的不可用，到后來表現優異，宛如從一架馬車進化成了一艘火箭，
剛剛討論了改造程序，我們看到其實這個改造程序說簡單也不簡單，說難其實也沒有太復雜，總體思路是一個先跑通再優化，從簡單到復雜的程序，因為在銀行業務里，大部分都是一些相對不算是特別復雜的SQL，特別復雜的SQL往往都是跑批類的，而銀行大部分業務都是高頻交易，所以，解決了高頻交易，代表解決了問題的百分之九十的問題，剩下只是花多少時間的問題，總結成一句話就是：“先解決高頻率，再解決跑批類”，
- 分布式事務
作為分布式資料庫，尤其是銀行場景的分布式資料庫，最關心的就是分布式事務，
比如銀行里A、B兩人需要轉帳，用戶A的賬戶是在第一個物理結點，用戶B的賬戶是在第二個物理結點，對于轉賬這個場景，也就是對A、B賬戶的余額的操作，要么全部成功，要么全部失敗，不能給A扣了款B沒有加款，或者B加了款A沒有扣款，這就是TDSQL分布式事務的保證，所以說，如果分布式資料庫不支持健壯的分布式事務，那么它很難適應銀行類金融場景，當然，分布式事務由于涉及到多個資料節點，同時需要額外做很多的校驗和通信，因而一定會有性能損耗，TDSQL這里通過大量優化僅損耗25%，TDSQL的分布式事務基于MySQL經典的兩階段提交，在MySQL的XA事務上二次開發，修復了大量官方BUG保證分布式事務的健壯性，
- 高可用部署架構
說完了分布式事務，再來聊聊銀行的高可用部署架構，這是一個標準的兩地三中心架構，同城部署，總行機房和災備機房兩個機房之間的資料同步基于TDSQL的強同步復制，保證在主機房寫成功的同時，至少在備機房的一個節點上落盤成功，異地機房，主要用來做異地的災備實體，
- 資料同步
下面我們再來聊聊資料同步，對銀行來說，尤其是第一家核心系統采分布式資料庫的銀行，無論上線前你講得再好，演練得再好，或者說測驗得再好，也還是有一定的不確定因素，這就引出了個Oracle災備的方案，將Oracle作為備胎和TDSQL保持實時同步關系，在極端情況下允許從TDSQL切換到Oracle，也許這個方案永遠都不會用，但是正因為有了這個兜底方案，對銀行來說用分布式資料庫才更有信心，
資料同步方案這里另一個設計是多源同步解決方案——TDSQL到其他異構資料庫的匯入匯出，TDSQL抱著一個開放的態度讓用戶選擇接入，并不綁架用戶，如果哪一天銀行客戶用了TDSQL，覺得用得不好，或者覺得TDSQL不滿足他的需求或有比它更好的，通過資料同步方案可以輕松將資料遷出，TDSQL支持業內標準格式的資料訂閱，方便資料的匯入匯出，
- 自動化資料庫運營管理
下面我們繼續再往下看到的是TDSQL自動化運營管理平臺，作為銀行科技部門的運維，希望盡可能快速上手，減少人員培訓成本，運維系統盡可能自動化高，集成化高，
赤兔監控就是一個資料庫的監控指標，提供上百項的資料庫監控，資料庫各項健康狀態、性能引數一目了然；監控通過結合智能告警，及時捕獲資料庫例外狀態，通知DBA相關責任人處理，扁鵲系統，是一套強大的智能DBA診斷系統，基于騰訊海量運維經驗，結合強大的語法、規則庫，對資料庫進行一鍵診斷、迅速定位性能問題，一鍵運維，顧名思義所有運維操作集成到頁面上，降低運維人員誤操作的概率，需要強調的是，我們TDSQL跟傳統資料庫廠商有什么不同，傳統資料庫廠商研發資料庫產品，賣給客戶使用，而我們在賣給客戶之前，首先在自己內部充分驗證和適用，先拿自己的業務體驗和采坑，
- 性能和成本雙優化
剛剛介紹了那么多，最后我們分享一下以張家港行為例，銀行傳統核心完成分布式改造之后達到的效果，主要是成本和性能兩方面，
先看性能，查詢交易100毫秒之內，高頻率交易300毫秒，貸款結息3分鐘，日終跑批14分鐘，這是銀行披露的資料，目前這個性能已經完全滿足張家港行未來十年的業務量，
再看成本，按照Oracle的架構，硬體方面需要采用大型機、小型機，張家港行采用騰訊云TDSQL分布式資料庫架構后的硬體成本，只有傳統架構成本的1/5甚至更低，此外，由于TDSQL是分布式的架構，支持水平擴展，通過不斷增加硬體資源可繼續提高吞吐量，
所以，當看到這樣的成本性價比，相信任何一個有商業頭腦的銀行，當目前核心涉及到更新換代時，肯定不會再像以往那么堅定的選擇國外廠商，而是更多考慮國內互聯網公司的分布式資料庫，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/296424.html
標籤：其它
上一篇：TiDB 學習筆記一（運維管理）