從數據庫巨人身上撕開一道口子

大咖介紹 蘇強，騰訊雲數據庫資深產品經理，擁有多年ToB產品策劃、產品運維經驗。曾在多個知名企業任職產品經理，主導或參與多款業內知名的B端產品從0到1過程，部分主導產品已實現同類產品佔有率第一。接手騰訊分佈式數據庫以來，主要負責騰訊雲分佈式數據庫功能策劃、市場能力建設、服務支撐能力建設和團隊建設等。

你們好，我是來自騰訊雲的蘇強。從騰訊雲分佈式數據庫商用那天起，我就在分佈式數據庫團隊裏，因此能夠很自豪地說，我是最瞭解騰訊雲分佈式數據庫的人之一。今天我將和你們分享近兩年來分佈式數據庫在金融行業裏真實應用的細節與核心。

1、金融行業現狀

目前國內大中型銀行主要以國外廠商提供的大型主機和數據庫解決方案來進行系統構建。因爲近年來金融業務量的不斷增加，以及銀行數字化轉型成爲必然趨勢。目前以國外大型主機和數據庫爲核心的架構已沒法知足大規模交易和數據處理的需求。

一方面：性能沒法知足業務不斷激增的處理需求，存在系統過載風險；另外一方面：自己價格比較昂貴，維護成本居高不下。

以手機銀行、網上理財、互聯網保險等爲表明的金融業務創新快速發展，推進新技術正之前所未有的速度與力度發生深層次變革。

這些技術發展，對金融服務模式帶來重大影響，使得金融行業向數字化、分佈式轉型成爲必然趨勢，金融業務創新與科技創新正在相互促進，重塑金融行業系統能力。

一、分佈式數據庫領域的百家爭鳴

| 多種架構長期共存： 分佈式數據庫通過這麼多年的發展，實際上並非一種新興的技術了，從最先基於中間件的模型開始到如今基於分佈式存儲的架構，這些架構一直在並存着往前發展，談不上哪一個更優秀，由於都各有各的應用場景。

| 多種技術棧卡位競爭： 分佈式技術目前發展的方向是，技術棧有兼容MySQL的，也有兼容Oracle的，也有兼容PG的，各技術棧如今互相卡位，在國內的廠商之間，幾乎每一個廠商都跟着一條線。

l 廠商互相PK： 目前投入的廠家，特別是在這兩年國家對這塊的支持力度和資本介入之下，作分佈式數據庫的廠家愈來愈多，造成了互相競爭的關係。

二、金融客戶應該如何選擇分佈式數據庫

拋開所謂的金融產品的可靠性、可用性等技術點之外，選擇一個金融分佈式數據庫最核心的要點我認爲是如下四方面：

l 質量可靠： 產品應該成熟可靠，通過大規模業務持續驗證，擁有較多的客戶案例和ISV集成經歷。
l 團隊建設： 創建能用、會用、用好國產數據庫的人才隊伍；造成一支具有高水平維護能力的隊伍。
l 持續演進： 背靠優質平臺或生態，產品能夠持續演進發展；廠商擁有一流的研發團隊和長期投入。
l 服務能力： 在國內主要地市創建健全分銷體系、培訓能力、服務團隊。不只包括數據庫，更能覆蓋金融全技術棧的服務能力。

三、騰訊雲分佈式數據庫解決方案

騰訊雲分佈式數據庫最先源自於騰訊的增值業務，從充值Q幣開始一直到財富通、微信支付、微衆銀行，騰訊的分佈式數據庫一直是基於開源的自主研發。最近幾年咱們開始逐漸面向產研結合和產用結合，在產研結合方面咱們和國內頂級高校創建了聯合實驗室，也在國際上發表了多篇頂級論文；在產用結合方面咱們和不少銀行創建了聯合實驗室，共同促進產品發展，目前主要應用的是咱們TDSQL和TBase兩條產品線。

2、金融應用實踐

接下來將分享一個關於某金融客戶主機下移過程的真實案例，但願能真正給到你們一些啓發。

拋開細枝末節，只聚焦在數據庫上，咱們怎麼樣把數據庫的核心往下切？當時咱們總結出瞭如下七個問題：

如何選擇分佈式技術棧；

如何設計信息技術創新節奏；

如何使用分佈式數據庫；

新老系統的切換；

分佈式的擴展容災方案；

如何對國產數據庫進行運維；

其餘典型場景分佈式數據庫如何適配。

一、分佈式技術棧的選擇：對主流方向都有佈局和應用

對於分佈式技術棧的選擇，目前有兩個主流方向，一個是兼容MySQL，一個是兼容Oracle。

兼容MySQL的優點是其分佈式技術棧比較成熟，易於團隊建設。基於MySQL的分佈式協議最先來自於國外的一些互聯網廠家，後逐漸引入到國內的互聯網廠家，包括國內的微信支付、螞蟻金服等幾個巨頭的支付廠家，其底座都是以兼容MySQL協議爲主，再加上這麼多年國內開發者對MySQL的研究，因此在此背景之下，金融機構的相關團隊建設是比較容易成型的。

兼容Oracle的優點是對整個金融系統的改造、遷移、使用成本相對較低，有可複用的部分而且方案相對簡單。

因此說這兩個技術棧方向都各有優點，騰訊雲由於金融業務足夠大因此覆蓋了這兩個方向的產品，都有本身的產品線，咱們如今都把它叫作分佈式數據庫產品線，分別是MySQL技術棧的以及Postgre技術棧的產品。

二、技術創新節奏

1）某大型銀行客戶的主機下移「五年計劃」

瞭解過技術棧的選擇，接下來就是考慮自身團隊適合哪款產品、選擇這款產品後怎麼設計核心系統等。如下是某大型銀行真實計劃的縮影，他們給整個過程設定了五年計劃原則：

技術團隊：創建一支熟悉分佈式數據庫技術棧的技術團隊；

分批改造：根據業務重要性，分批分階段改造業務系統；

業務磨合：技術方案應在不影響宏觀穩定，確保業務與數據庫磨合；

技術複用：該技術應該是能夠複用或容易創建的；

全量切換：應該是在徹底磨合好之後，再全量切換。

而且分紅四種節奏開展落地：

2018~2019年，團隊招聘與培養：肯定基於Oracle+MySQL實現雙技術棧團隊建設，並選擇互聯網銀行業務選擇開源MySQL方案打磨團隊；

2020年，（試點）核心系統改造：團隊對MySQL熟悉後，實現核心業務系統基於騰訊雲TDSQL上線並開始運營；

2021年，新老系統並行，剩餘系統改造：老業務系統不下線，數據保證明施同步回老業務系統，若是新業務系統一旦故障確保老系統可用；

2022年，最終核心交易全量切換：在運行一段時間後，確保新系統徹底穩定後，再封存老系統。

2）某銀行客戶傳統核心業務系統改造過程

以上是另外一個銀行客戶的案例，他們的客戶規模相對於上面的銀行小一些，因此進程較快。他們在2018年4月選擇了某一個技術棧方向，而且開始POC測試，聯合着XXX（英文）在2018年末到2019年初就在業務系統改造生產完成，而且在2019年上半年經過了相關專家機構的評審，正式上線。在2019年年中投產，逐步投產後運行很是穩定，並且性能較以前有較大的提高，因此2019年末整個核心系統所有下移投產。整個過程經歷了差很少兩年的時間，過程當中整個項目團隊的工做是很是緊張的，並且也藉助了大量的成熟經驗和長亮科技能力。

三、數據層下移的拆分策略

1）水平拆分&垂直拆分

在執行了相應的規劃之後，就要考慮數據庫改造中數據層下移的拆分策略。說到水平拆分就不得不說起垂直拆分，垂直拆分通常是在SOA時代，基於業務垂直拆分。

分佈式改造最主要的仍是對其中一些業務核心戶進行水平拆分，使其可以適應新時代新的科技金融業務的發展。但也並非全部的系統都須要分佈式改造，有些規模比較小的系統就不必。騰訊的產品是集中式和分佈式組合在一塊兒的，便於客戶只買一個產品，能知足幾乎全部數據庫的需求。

2）水平拆分的主要方案

從實踐來說，數據層下移的拆分方案主要分爲三種：

第一種是按客戶維度拆分：如上圖所示，主要面向客戶規模比較大、無明顯分佈性、交易金額小、筆數多等這種對私類業務，通常的拆分策略是一致性哈希。

第二種是按分公司（法人）維度拆分：如上圖所示，主要面向集團，其業務是基於分公司維度展開的，主要有幾個特色——業務按分公司維度展開；交易/清算等以該維度展開；不一樣分公司交易規模區分明顯；總部搭建業務系統和數據收口；分公司總數少但交易數量多。因此騰訊提供了一種叫虛擬組的能力，能夠在分公司分佈的基礎上再進行拆分，幫助用戶去提高。好比一個發展比較快的東南亞分公司，可能原來只須要一個小的分片，兩年後爆發式增加就能夠基於這種架構進行快速無縫的擴展。

第三種是按時間維度拆分：如上圖所示，一般是訂單類的系統，並且按時間維度會涉及到大促時期呈峯值增加的問題。這種場景下，騰訊的產品能夠提供一種二級分區的能力，能夠按照時間分區，這就意味着不管歸到歷史庫也好仍是這一時間階段交易規模比較大也好，均可以均衡地負載性能。

四、新老系統的切換：DTS-DBBridge

接下來就會涉及到研發，一旦涉及到研發就要考慮整個業務系統遷移的流程。這個流程從最開始的業務溝通，騰訊就能夠開始介入，騰訊的技術人員能夠經過咱們成熟的遷移工具DBBridge輸出對業務系統遷移的評估報告，同時配合開發人員進行業務系統改造、實施、新老系統的並行上線以及到最後的切換，整個服務體系均可以造成一個閉環。

五、國產數據庫的運維：DBBrain&分佈式數據庫管理系統

遷移完成後就涉及到如何管理數據庫，這裏涉及到咱們另外一個方案DBBrain，它可以幫助用戶從全局角度分析分佈式數據庫運行的狀況，其中積累了騰訊海量的運維經驗。

六、分佈式多活多SET化擴展容災方案

運維起來之後，隨着運行一年到兩年，某些核心就要開始考慮是否要符合監管的要求，是否要作兩地三中心和容災，甚至隨着金融業務呈爆發式發展，原有的機房已經不能知足需求，須要換多機房方案。

傳統的兩地三中心容災方案，從金融科技發展角度會呈現出一些小問題，好比容災須要人工干預，當真的面臨事故時，是否敢作切換的決策？實際上不少金融IT從業者都不敢打包票。另外就是備機房常態下無流量，利用率較低，因此如今發展出多活的容災方案，簡單來講就是把業務系統經過一層網關進行一個按SET的劃分，每個SET下面都對應一套數據庫，這個數據庫既能夠是集中式也能夠是分佈式。騰訊裏像微信支付，都是使用多SET的模型。

SET的主從之間是採用數據庫的強同步，SET與SET之間同類業務採用數據同步模型，由於上層的SET作了業務拆分，因此兩個SET組之間的數據是不衝突的，能夠互相進行同步。這類架構目前也在國內的某頭部保險公司，一樣是騰訊雲的客戶，已經試驗了兩地四中心的架構，到目前爲止已經穩定運行超過9個月，單個SET能承載的理論容量是10TB，理論TPS是5K以上，並且性能能夠基於SET化的分佈式擴展往上加，因此SET化能夠擴展的能力是很強的。

七、典型場景

騰訊的產品還有哪些場景真正面向金融行業？下面給你們列舉幾個典型場景。

1）異常場景的恢復&全局一致性數據分析

第一種是異常場景的恢復和全局一致性數據分析，這個場景的功能和模型是差很少的，只是應用場景不同。舉個簡單的例子，到年終結算的時候我須要2020年凌晨零點整的整年所有數據的一致性快照，能夠有兩種方式，第一種是生成一個新的實例，第二種是生成一個新的快照。這裏會存在一個問題，由於分佈式狀況下服務器的系統時鐘不必定一致，因此如圖中上者須要進行分佈式的補查，下者須要一個GTS絕對時間戳來保證數據的準確。

2）分佈式事務實時強一致

第二種是分佈式事務實時強一致的能力，舉個例子，假設我有五張銀行卡，由於我要還房貸因此錢從這些卡之間轉來轉去。這時我媳婦正好在我轉帳時來查帳，就會有兩種結果：第一，我媳婦過十分鐘後來查帳，她查詢到的就是我轉帳後的餘額狀況，這種叫最終一致性；第二，我媳婦在我轉帳過程當中就來查帳，這時就叫實時一致性。實時一致性就是要保證在交易過程當中，即時隨時查帳都能獲得最準確的結果，這也是咱們數據庫當前可以支持的一種能力。

3）渠道類業務冷熱數據不均

第三種是渠道類業務冷熱數據不均，針對金融行業由於有大量的渠道業務，會出現嚴重的冷熱不均衡。以微信支付爲例，京東是咱們最大的渠道之一，它一家的體量頂得上街邊小的收銀渠道幾千家的體量，這就會遇到一個問題，個人大商戶和小商戶怎麼分佈才能使得整個資源利用率是最佳的，因此咱們提出了冷熱數據均衡的能力。我能夠把一堆小商戶放到專門小商戶group裏面，大商戶放在大商戶的group裏面。

4）複雜SQL處理（跑批等）

第四種是複雜SQL處理（跑批等），在金融行業裏有時使用開源的分佈式數據庫一遇到跑批就死掉，這是很正常的現象，由於數據量大了之後計算節點沒法承載。因此咱們提出了基於CPU的策略優化方案，簡單來講相似於並行計算，把計算層的節點、計算層要作的事情往下推，推到數據層來作，本來須要在計算層幾百個G的數據，下推後須要計算層處理的數據可能就只有幾個G。由於經過計算層和計算層之間，數據能夠作到打通和交流，這樣就極大的提升了批處理的效率。

5）分佈式彈性

第五種是分佈式彈性，也是金融行業會遇到的比較典型的場景。上圖是美國今年熔斷，富途證券的峯值達到50億次。因此分佈式的擴展性能幫助咱們在面對這種比較極端的、沒法預料的狀況下，整套性能可以很快速的擴展到所須要的目標。

3、總結

4、Q & A

Q1：我瞭解如今國內作分佈式改造無外乎是三種方式，一種是騰訊這種直接改造傳統的結構化數據庫，騰訊這兩個產品都應該是這種模式吧？還有一種是增長一層分佈式中間件，國內也有廠商作；第三種是基於谷歌Spanner論文作的產品。請問您怎麼看這三種方案的優缺點？

蘇強：您說的這種方式就是剛纔我提到的如今多種業務架構並存，騰訊的方式準確來講也不是基於中間件簡單改的，它其實是把三種技術能力進行了融合。針對您所說的三種方式，如今確實各有優缺點。

首先基於谷歌Spanner的方式，它的優勢是想象空間比較大，因此很容易實現行列混合存儲能力。缺點是它的計算層層比較重，因此它的最大可擴展性和最大的理論性能是有限制的；另外由於該技術是新發展技術，因此大規模應用於稱金融行業可能還須要一些時間。

而後基於中間件的方式，優勢是性能特別好，缺點就是業務系統要配合，並且對於語法的兼容性相對來講比較差，不太適合金融行業。

騰訊是屬於偏二者中間模型，既吸取了NewSQL的能力，又支持像分佈式中間件的可靠性能。它的特色是性能、語法兼容性相對來講比較高、底層存儲當前雖然是結構化存儲，由於咱們把計算層往上提了，提了之後下面存儲究竟是用MySQL、用PG，仍是用NewSQL的KV存儲？對咱們來講設計就比較靈活，因此咱們內部三種形態都有使用。目前由於是面向金融行業，主要仍是商用的最成熟，因此主要仍是推咱們本身最成熟的TDSQL和TBase那一套方案。將來咱們內部也有新的方案也在打磨，咱們也會發布新的產品能力出來。

Q2：企業裏使用TDSQL的話，您是建議部署在物理機上仍是騰訊私有云平臺上？

蘇強：由於數據庫自己是一個軟件，理論上來講是能夠部署在物理機和虛擬機上的。但由於生產環境目前虛擬機對數據庫所須要的高IO，下面IO優化作得效果不太明顯，因此咱們目前的建議是部署在物理機上。若是是一些測試環境或非核心環境也是能夠部署在虛擬機上的。

爲了幫助你們部署在物理機上，方便管理以及進行資源的有效分配，咱們全部數據庫部署在物理機上都會有一套本身的虛擬化模型，也就是說您能夠在物理機上抽象出相似雲的多租戶的實例模型出來，能夠給多個業務單位或者我的使用。

本文由博客一文多發平臺 OpenWrite 發佈！