本文是騰訊雲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是分散式的架構，支援水平擴充套件，通過不斷增加硬體資源可繼續提高吞吐量。
所以，當看到這樣的成本價效比，相信任何一個有商業頭腦的銀行，當目前核心涉及到更新換代時，肯定不會再像以往那麼堅定的選擇國外廠商，而是更多考慮國內網際網路公司的分散式資料庫。