在2004年，騰訊充值、財付通等業(yè)務爆發(fā)發(fā)展，但那時騰訊和所有的創(chuàng)業(yè)公司有個共同點—“窮”，在這樣的背景下，TDSQL逐步誕生了，所以騰訊金融類業(yè)務從一開始就沒有IOE。

因為期間經(jīng)歷了業(yè)務層對拆分的濫用，主從數(shù)據(jù)不一致導致的數(shù)據(jù)準確性問題，以及上百臺設備集群的管理問題等。

所以，從08年開始，團隊決定重構(gòu)TDSQL解決方案，針對金融類業(yè)務的特點，列出以下幾個要點：

l 數(shù)據(jù)強一致的要求

l 數(shù)據(jù)庫集群的可用性、穩(wěn)定性和容災要求要達到銀行標準

l 業(yè)務無需拆分超大表，數(shù)據(jù)庫自動拆分

l 接入要簡單，老業(yè)務改造要小，必須兼容MySQL協(xié)議

l 符合并高于金融行業(yè)信息安全監(jiān)管要求

TDSQL的軟件架構(gòu)組成

整體來說，TDSQL是由決策調(diào)度集群/GTM，SQLEngine、數(shù)據(jù)存儲層等核心組件組成的，其每個模塊都基于分布式架構(gòu)設計，可以實現(xiàn)快速擴展，無縫切換，實時故障恢復等，通過這一架構(gòu)，TDSQL的Noshard、Shard、TDSpark實例可以混合部署在同一集群中。并且使用簡單的x86服務器，可以搭建出類似于小型機、共享存儲等一樣穩(wěn)定可靠的數(shù)據(jù)庫。

在架構(gòu)上，TDSQL的核心思想只有兩個：數(shù)據(jù)的復制（replica）和分片（sharding），其它都是由此衍生出來的。其中，

replica配合故障的檢測和切換，解決可用性問題；

sharding配合集群資源調(diào)度、訪問路由管理等，解決容量伸縮問題。

同時，因replica引入了數(shù)據(jù)多副本間的一致性問題和整體吞吐量下降的問題，而sharding的引入也會帶來一定的功能約束。

在最終實現(xiàn)上，TDSQL由Scheduler、Gateway、Agent三個核心組件加上MySQL組成，其中：

Scheduler是管理調(diào)度器，內(nèi)部又分為zookeeper和scheduler server；

Gateway為接入網(wǎng)關(guān)，多個網(wǎng)關(guān)組成一個接入層；

Agent是執(zhí)行代理，與MySQL實例一起，構(gòu)成數(shù)據(jù)節(jié)點。多個數(shù)據(jù)節(jié)點構(gòu)成服務單元SET。

相比單機版的MySQL，TDSQL的優(yōu)勢主要體現(xiàn)在集群維度，包括容災、高一致性、高彈性等。

注：√ 支持，×不支持， ○不適用

數(shù)據(jù)一致性考驗

在金融行業(yè)，銀行、風控、渠道等第三方通常通過讀寫分離方式來查詢數(shù)據(jù)，而在互聯(lián)網(wǎng)行業(yè)，由于x86相對較高的故障率，導致數(shù)據(jù)可能經(jīng)常性的出現(xiàn)錯亂、丟失場景。為了解決這個問題，就必須要求主從數(shù)據(jù)的強一致和良好的讀寫分離策略。其關(guān)鍵在于，如何實現(xiàn)強同步復制技術(shù)。

由于MySQL的半同步和Galera模式不僅對性能的損耗是非常大的，而且數(shù)據(jù)同步有大量毛刺，這給金融業(yè)務同城雙中心或兩地三中心架構(gòu)容災架構(gòu)帶來了極大的挑戰(zhàn)。

為什么會這樣呢？從1996年的MySQL3.1.1.1版本開始，業(yè)務數(shù)據(jù)庫通常跑在內(nèi)網(wǎng)，網(wǎng)絡環(huán)境基本較好，因此MySQL采用的是每個連接一個線程的模型，這套模型最大的好處就是開發(fā)特別簡單，線程內(nèi)部都是同步調(diào)用，只要不訪問外部接口，支撐每秒幾百上千的請求量也基本夠用，因為大部分情況下IO是瓶頸。

但隨著當前硬件的發(fā)展，尤其是ssd等硬件出現(xiàn)，IO基本上不再是瓶頸，如再采用這套模型，并采用阻塞的方式調(diào)用延遲較大的外部接口，則CPU都會阻塞在網(wǎng)絡應答上了，性能自然上不去。

因此，TDSQL引入線程池，將數(shù)據(jù)庫線程池模型(執(zhí)行SQL的邏輯)針對不同網(wǎng)絡環(huán)境進行優(yōu)化，并支持組提交方案。例如，在binlog復制方案上，我們將復制線程分解：

1、任務執(zhí)行到寫binlog為止，然后將會話保存到session中，接著執(zhí)行下一輪循環(huán)去處理其它請求了，這樣就避免讓線程阻塞等待應答

2、MySQL自身負責主備同步的dump線程會將binlog立即發(fā)送出去，備機的io線程收到binlog并寫入到relaylog之后，再通過udp給主機一個應答

3、在主機上，開一組線程來處理應答，收到應答之后找到對應的會話，執(zhí)行下半部分的commit，send應答，綁定到epoll等操作。綁定到epoll之后這個連接又可以被其它線程檢測到并執(zhí)行

改造后，使得TDSQL可以應對復雜的網(wǎng)絡模型。當然，深入了解過MySQL同步機制的朋友可能會發(fā)現(xiàn)上述方案還有小缺陷：當主機故障，binlog沒有來得及發(fā)送到遠端，雖然此時不會返回給業(yè)務成功，備機上不存在這筆數(shù)據(jù)，然而在主機故障自愈后，主機會多出來這筆事務的數(shù)據(jù)。解決方法是對新增的事務根據(jù)row格式的binlog做閃回，這樣就有效解決了數(shù)據(jù)強一致的問題。

2018年初，英特爾技術(shù)團隊使用sysbench測試方案，在跨機房、相同機型、網(wǎng)絡和參數(shù)配置和高并發(fā)下測試，TDSQL強同步復制平均性能是MySQL5.7異步復制的1.2倍。

基于規(guī)則和基于代價的查詢引擎

當前大多數(shù)分布式數(shù)據(jù)庫都設計的是基于規(guī)則的查詢引擎(RBO)，這意味著，它有著一套嚴格的使用規(guī)則，只要你按照它去寫SQL語句，無論數(shù)據(jù)表中的內(nèi)容怎樣，也不會影響到你的“執(zhí)行計劃”，但這意味著該規(guī)則復雜的數(shù)據(jù)計算需求不“敏感”。雖然金融業(yè)務都有自己的數(shù)據(jù)倉庫，然而也會經(jīng)常需要在OLTP類業(yè)務中執(zhí)行事務、JOIN甚至批處理。

TDSQL在SQLENGINE實現(xiàn)了基于代價的查詢引擎(CBO)，SQL經(jīng)過SQLENGINE的詞法，語法解析，語義分析和SQL優(yōu)化之后，會生成分布式的查詢計劃，并根據(jù)數(shù)據(jù)路由策略（基于代價的查詢引擎）進行下推計算，最后對匯總的數(shù)據(jù)返回給前端。

而作為分布式的計算引擎，在存儲與計算引擎相分離的情況下，非常重要的一環(huán)就是如何將計算盡量下推的下面的數(shù)據(jù)存儲層。因此TDSQL的SQLENGINE在經(jīng)過大量業(yè)務打磨后，實現(xiàn)了基于shard key下推，索引條件下推，驅(qū)動表結(jié)果下推，null下推，子查詢下推, left join轉(zhuǎn)化成inner join等多達18種下推優(yōu)化手段，盡量降低數(shù)據(jù)在多個節(jié)點傳輸帶來的壓力，以提供更好的分布式查詢的能力，支撐金融交易的關(guān)聯(lián)操作。

全局事務一致性與全局時間戳服務GTM

金融行業(yè)對事務處理的需求極高，轉(zhuǎn)賬、扣費，無一不是使用事務，而騰訊是少數(shù)幾個將分布式事務處理，分布式JOIN用于金融核心系統(tǒng)的企業(yè)。

TDSQL仍然是通過經(jīng)典的XA兩階段提交加兩階段封鎖協(xié)議實現(xiàn)了強分布式事務的語義，以支撐金融場景對事務管理的需求。在使用語法上與MySQL完全一樣，即后端的分布式事務處理對業(yè)務使用方是完全不感知，以保證兼容性。

在二階段提交實現(xiàn)上，在begin的時候從GTM獲取全局遞增的事務ID，然后在參與事務的各個子節(jié)點通過這個事務ID開啟事務，進行各種DML操作，提交的時候先對各個子節(jié)點執(zhí)行prepare。當prepare成功之后，再更新全局事務ID的事務狀態(tài)，同時獲取到一個新的事務ID作為提交的事務ID對各個子事務進行異步并行化的提交，提供更好的事務操作性能。

當前GTM以一主兩從的方式運行，主從節(jié)點底層通過 raft 協(xié)議進行數(shù)據(jù)的同步以及主從切換，內(nèi)部交互以及對外通訊均基于 grpc 協(xié)議。當前TDSQL的GTM組件性能完全可以滿足金融業(yè)務需求：

l 全局時間戳：≈180w – 190w TPS，8 Clients，主節(jié)點CPU 跑滿情況下（24core），內(nèi)存消耗約23GB；

l 遞增序列號：≈750w – 780w TPS，8 Clients，10萬個 key，主節(jié)點 CPU 跑滿情況下 ，內(nèi)存 消耗約30GB；

從節(jié)點資源消耗：因為所有請求均由Leader節(jié)點完成響應，從只負責接受來自于 主節(jié)點的 raft 數(shù)據(jù)同步請求，并且 從節(jié)點上不緩存任何數(shù)據(jù)，因此 CPU 和 內(nèi)存消耗都在極低的程度；因此，一般場景下，通常GTM與調(diào)度決策集群可以混合部署，極大的節(jié)省了物理設備成本。

TDSQL的HTAP能力

TDSQL除了提供計算下推，分布式事務等特性，也針對OLAP需求演進了TDSpark特性。

簡單來說，是將SQLEngine基于OLAP場景做了修改，保留原生的MySQL協(xié)議接入能力。因此業(yè)務繼續(xù)可以通過訪問MySQL的渠道接入到OLAP-SQLEngine，OLAP-SQLEngine在這個時候不是將分布式的查詢計劃直接下推到各個數(shù)據(jù)庫節(jié)點，而是引入一個中間層，目前是采用SPARKSQL,通過SPARKSQL強大的計算能力能顯著提升復雜SQL的執(zhí)行性能。另外為了確保分析操作與在線的OLTP業(yè)務隔離，我們TDSQL的數(shù)據(jù)層為每份數(shù)據(jù)增加1個watch主數(shù)據(jù)庫的數(shù)據(jù)異步節(jié)點，確保分析操作與在線業(yè)務操作不互相影響。

數(shù)據(jù)安全與容災

數(shù)據(jù)安全和容災是金融類業(yè)務的命脈，而TDSQL現(xiàn)已經(jīng)應用在多個銀行、保險的公有云或私有云環(huán)境。符合國家等級保護信息安全要求，通過銀保監(jiān)會相關(guān)審核，獲得了包括ISO，SOC等國內(nèi)和國際標準。

而在容災能力方面，TDSQL可以支持：

l 同城數(shù)據(jù)強一致下的雙活：當前騰訊公有云和金融云有大量的客戶都選擇了類似方案。

l 主從讀寫分離的異地多活：該方案適用于應用完全不做任何改造，就可以實現(xiàn)跨城多活的能力。當前TDSQL很多客戶不想對業(yè)務改造，但是又想具備跨城多活和切換的能力，通常選擇這個方案。

l 多主的異地多活架構(gòu)，并支持雙向同步：通過應用層根據(jù)用戶維度做了區(qū)分之后，可以使得多套TDSQL數(shù)據(jù)庫分別承載不同的業(yè)務進行讀寫事務訪問，實現(xiàn)完全的多活能力，但是如果業(yè)務系統(tǒng)無法保證調(diào)度安全和數(shù)據(jù)的區(qū)分，可能存在數(shù)據(jù)異常的風險。

l 多主的異地多活架構(gòu)，多套主從架構(gòu)：綜合了前面兩種架構(gòu)，實現(xiàn)了完全的異地多活+讀寫分離的能力，并且即使業(yè)務層路由錯誤，也不會引起數(shù)據(jù)異常。當然，對應的應用層也要能配合修改。

當然越高要求對部署的要求約復雜，目前公有云已經(jīng)提供了前面兩種方案可供大家試用。

數(shù)據(jù)庫自治運營

為了保證系統(tǒng)的運行做到一切盡在掌控之中，TDSQL不僅有完善的管控系統(tǒng)（赤兔）來完成系統(tǒng)的自動化管理，從可用性、安全、效率、成本維度進行全方位管控。還在赤兔中引入了“數(shù)據(jù)庫自治運營”的理念，構(gòu)建了一套能自我學習的智能檢測平臺（簡稱扁鵲）。

以SQL優(yōu)化為例，該系統(tǒng)能自動抽象出當前效率最差的若干SQL，并將這些通過解析SQL生成AST語法樹，分析語法樹中表的連接方式和連接字段，然后遍歷語法樹中的過濾，排序等關(guān)鍵字段，再次分析各字段的區(qū)分度，對于區(qū)分度較高的字段會提供推薦優(yōu)化方案，綜合字段區(qū)分度，過濾規(guī)則，表連接順序等多個因素推提供優(yōu)化建議。

TDSQL的自治運營的最終目標是利用公有云龐大的環(huán)境進行自我學習和自我進化，做到無需人工干預即可進行更新、調(diào)整和修復，從而解放人力、減少人為差錯，幫助企業(yè)節(jié)約管理及經(jīng)濟成本、降低風險。

金融業(yè)務的數(shù)據(jù)庫發(fā)展及展望

金融業(yè)務涉及國計民生的重點業(yè)務，一個小小的BUG，一個操作失誤，就可能影響到數(shù)以萬計的百姓資產(chǎn)準確性。正因為這樣的責任，騰訊云TDSQL團隊始終堅守則“本心”。

目前，TDSQL已在北京、深圳、成都三地建立研發(fā)團隊，并通過CMMI3認證，同時在開源社區(qū)擁有自己的開源分支。值得一提的是TDSQL已獲得包括ISO27001、ISO22301、PCI DSS、SOC審計，工信部分布式數(shù)據(jù)庫測試，IT168技術(shù)突破大獎，多項國家或國際認證和行業(yè)殊榮。并與包括中國人民大學，中國銀行等開展產(chǎn)研結(jié)合、產(chǎn)用結(jié)合，并取得諸多創(chuàng)新成績。

展望2019年，TDSQL將持續(xù)通過產(chǎn)研結(jié)合、產(chǎn)用結(jié)合的方式進行研發(fā)突破，并開放商用更多特性，擁抱開源社區(qū)。

zhangnn