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

因?yàn)槠陂g經(jīng)歷了業(yè)務(wù)層對(duì)拆分的濫用，主從數(shù)據(jù)不一致導(dǎo)致的數(shù)據(jù)準(zhǔn)確性問(wèn)題，以及上百臺(tái)設(shè)備集群的管理問(wèn)題等。

所以，從08年開(kāi)始，團(tuán)隊(duì)決定重構(gòu)TDSQL解決方案，針對(duì)金融類(lèi)業(yè)務(wù)的特點(diǎn)，列出以下幾個(gè)要點(diǎn)：

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

l 數(shù)據(jù)庫(kù)集群的可用性、穩(wěn)定性和容災(zāi)要求要達(dá)到銀行標(biāo)準(zhǔn)

l 業(yè)務(wù)無(wú)需拆分超大表，數(shù)據(jù)庫(kù)自動(dòng)拆分

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

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

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

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

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

replica配合故障的檢測(cè)和切換，解決可用性問(wèn)題；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、MySQL自身負(fù)責(zé)主備同步的dump線(xiàn)程會(huì)將binlog立即發(fā)送出去，備機(jī)的io線(xiàn)程收到binlog并寫(xiě)入到relaylog之后，再通過(guò)udp給主機(jī)一個(gè)應(yīng)答

3、在主機(jī)上，開(kāi)一組線(xiàn)程來(lái)處理應(yīng)答，收到應(yīng)答之后找到對(duì)應(yīng)的會(huì)話(huà)，執(zhí)行下半部分的commit，send應(yīng)答，綁定到epoll等操作。綁定到epoll之后這個(gè)連接又可以被其它線(xiàn)程檢測(cè)到并執(zhí)行

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

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

基于規(guī)則和基于代價(jià)的查詢(xún)引擎

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

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

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

全局事務(wù)一致性與全局時(shí)間戳服務(wù)GTM

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

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

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

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

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

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

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

TDSQL的HTAP能力

TDSQL除了提供計(jì)算下推，分布式事務(wù)等特性，也針對(duì)OLAP需求演進(jìn)了TDSpark特性。

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

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

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

而在容災(zāi)能力方面，TDSQL可以支持：

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

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

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

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

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

數(shù)據(jù)庫(kù)自治運(yùn)營(yíng)

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

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

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

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

金融業(yè)務(wù)涉及國(guó)計(jì)民生的重點(diǎn)業(yè)務(wù)，一個(gè)小小的BUG，一個(gè)操作失誤，就可能影響到數(shù)以萬(wàn)計(jì)的百姓資產(chǎn)準(zhǔn)確性。正因?yàn)檫@樣的責(zé)任，騰訊云TDSQL團(tuán)隊(duì)始終堅(jiān)守則“本心”。

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

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

zhangnn

<nav id="ryk28"></nav>