騰訊金融級數(shù)據(jù)庫TDSQL的架構(gòu)與應(yīng)用

騰訊云金融級數(shù)據(jù)庫CDB for TDSQL （Cloud DataBase for Tecent Distribute
SQL）是一個適用于OLTP場景且與MySQL 5.5 、5.6兼容的分布式關(guān)系型數(shù)據(jù)庫。

其前身是騰訊計費(fèi)平臺部為托管公司的虛擬賬戶康谆，如QB陪每、Q點(diǎn)催享、包月服務(wù)敢艰、游戲的二級賬戶等數(shù)據(jù)而打造的高性能數(shù)據(jù)庫集群侦鹏。在支持各大業(yè)務(wù)實(shí)時在線交易順暢進(jìn)行的同時飒炎，保證在各種災(zāi)難場景下數(shù)據(jù)的一致性埋哟、可用性。目前已經(jīng)承載了包括webank郎汪、米大師等多家金融領(lǐng)域的主要業(yè)務(wù)數(shù)據(jù)赤赊。下面主要介紹TDSQL的核心架構(gòu)和應(yīng)用場景。

金融領(lǐng)域數(shù)據(jù)庫的挑戰(zhàn)：

數(shù)據(jù)高一致性：

對金融業(yè)務(wù)來講煞赢，數(shù)據(jù)的強(qiáng)一致（Consistency）尤為重要抛计，因?yàn)槿绻霈F(xiàn)數(shù)據(jù)丟失，就意味著交易的丟失照筑，這會給組織或用戶帶來直接的金錢方面損失吹截，也有損企業(yè)商譽(yù)和信瘦陈。因此，數(shù)據(jù)的一致性是DBA應(yīng)該最需要考慮的問題之一波俄。然而晨逝，傳統(tǒng)數(shù)據(jù)庫如果不使用共享存儲的情況下很難做到主庫出問題時數(shù)據(jù)不丟失。即使采用一些強(qiáng)同步的方案進(jìn)行改造懦铺，也會造成數(shù)據(jù)庫性能的下降捉貌，無法滿足業(yè)務(wù)高并發(fā)需求。

服務(wù)高可用性：

隨著業(yè)務(wù)需求的不斷提高冬念，搭建一個數(shù)據(jù)庫高可用環(huán)境已經(jīng)成為很多企業(yè)迫切的需求趁窃。確保企業(yè)中的計算資源持續(xù)可用性是DBA的主要目標(biāo)之一。如果支持應(yīng)用程序的數(shù)據(jù)庫不可用刘急，不僅會帶來大量投訴或用戶流失棚菊，也會給組織帶來金錢方面的損失，損失信譽(yù)和商叔汁。高可用性和減少停機(jī)時間是數(shù)據(jù)庫系統(tǒng)的目標(biāo)统求，在諸如訂單、支付等需要24*7無障礙運(yùn)行的金融業(yè)務(wù)環(huán)境中尤其如此据块。

高并發(fā)和益伸縮性：

互聯(lián)網(wǎng)金融的到來讓金融服務(wù)向高效率码邻、碎片化、低成本的方向快速轉(zhuǎn)化另假。數(shù)據(jù)體量不斷膨脹的同時像屋，對業(yè)務(wù)請求的響應(yīng)時間要求也愈加苛刻。在保證前兩點(diǎn)的前提下边篮，不斷提升系統(tǒng)容量和吞吐率，保證毫秒級請求響應(yīng)時長也是一個必不可少的能力戈轿。

投資和回報：

當(dāng)前企業(yè)信息化的投入越發(fā)理性，決定企業(yè)信息系統(tǒng)構(gòu)成的除了基礎(chǔ)架構(gòu)思杯，通常還包括企業(yè) 的預(yù)算模型。對于或大或小的業(yè)務(wù)系統(tǒng)色乾，在保證高一致性和高可用性的同時，也必須要考慮到企業(yè)預(yù)算和成本案怯。商業(yè)數(shù)據(jù)庫基于許可的采購模式，勢必會導(dǎo)致建設(shè)成本高昂殴泰，難以擴(kuò)展，且需要大量的資源來配置和維護(hù)悍汛。事實(shí)上，為維持可用离咐、穩(wěn)定的生產(chǎn)環(huán)境甚至非生產(chǎn)環(huán)境谱俭，企業(yè)需要不斷地投入建設(shè)和管理費(fèi)用，最終導(dǎo)致企業(yè)為數(shù)據(jù)庫資源投入巨額成本宵蛀。

騰訊云金融級云數(shù)據(jù)庫解決方案

簡介

CDB for TDSQL的誕生經(jīng)歷了十余年：

2002年昆著，基于運(yùn)營商SP業(yè)務(wù)，騰訊數(shù)據(jù)庫團(tuán)隊(duì)開始對 MySQL進(jìn)行改造术陶；
2004年凑懂，騰訊互聯(lián)網(wǎng)增值業(yè)務(wù)開始爆發(fā)，業(yè)務(wù)量的爆炸給數(shù)據(jù)庫層帶來了巨大擴(kuò)容壓力梧宫，這就開始引入分庫表機(jī)制來解決難題接谨；
2008年，騰訊游戲塘匣、QQ空間脓豪、財付通等各類業(yè)務(wù)再次爆發(fā)，為提高可用性忌卤，減少故障帶來的損失和投訴扫夜，騰訊數(shù)據(jù)庫團(tuán)隊(duì)全力解決一致性這個問題，引入多種機(jī)制保障主備數(shù)據(jù)的一致性驰徊，并提供數(shù)據(jù)自動恢復(fù)的能力笤闯。
2010年，基于正在火熱的互聯(lián)網(wǎng)支付業(yè)務(wù)超高可用性棍厂、超高并發(fā)和極短響應(yīng)需求望侈，騰訊數(shù)據(jù)庫團(tuán)隊(duì)啟動高一致（分布式）集群存儲項(xiàng)目，最終達(dá)成了完全自動化的勋桶，在數(shù)據(jù)底層實(shí)現(xiàn)跨IDC的強(qiáng)同步、跨城容災(zāi)侥猬、切換一致性保障例驹、數(shù)據(jù)自動分片、集群管理等能力退唠。
2012年鹃锈，騰訊內(nèi)部正式給這款產(chǎn)品命名為TDSQL（Tecent Distribute SQL），且為了提高擴(kuò)展性和開放性瞧预，將MariaDB作為數(shù)據(jù)庫引擎的基礎(chǔ)屎债。在后續(xù)兩年時間仅政，陸續(xù)支撐米大師（Midas）圆丹、微眾銀行（WeBank）等多個兄弟業(yè)務(wù)的上線辫封，并針對銀行場景的數(shù)據(jù)關(guān)系模型設(shè)計了關(guān)系緊密的數(shù)據(jù)聚合倦微，同時將跨節(jié)點(diǎn)的分布式架構(gòu)轉(zhuǎn)換擴(kuò)展到單機(jī)架構(gòu)欣福，有效的覆蓋了大中小多層次的用戶拓劝。
2015年凿将，TDSQL正式進(jìn)駐騰訊云牧抵，并更名為騰訊云金融級數(shù)據(jù)庫CDB for TDSQL犀变，開始面向騰訊之外的企業(yè)提供金融級云數(shù)據(jù)庫服務(wù)获枝。

架構(gòu)

系統(tǒng)由三個模塊組成：Scheduler省店、Agent懦傍、網(wǎng)關(guān)粗俱，三個模塊的信息交換都是通過ZooKeeper完成寸认，極大簡化了各個節(jié)點(diǎn)之間的通信機(jī)制偏塞。

先說下Set這個邏輯概念：由一主多從多個節(jié)點(diǎn)構(gòu)成烛愧，每個節(jié)點(diǎn)包含一個Mysql實(shí)例和一個Agent實(shí)例怜姿，是承載數(shù)據(jù)存儲和服務(wù)的底層物理數(shù)據(jù)庫。一個或多個set可以通過網(wǎng)關(guān)形成一個邏輯數(shù)據(jù)庫蚁堤。

Scheduler作為集群的管理調(diào)度中心披诗，主要功能包括：

管理set呈队，提供創(chuàng)建宪摧、刪除set几于、set內(nèi)節(jié)點(diǎn)替換等工作所有的DDL操作統(tǒng)一下發(fā)和調(diào)度
監(jiān)控set內(nèi)各個節(jié)點(diǎn)的存活狀態(tài)沿彭，當(dāng)set內(nèi)主節(jié)點(diǎn)故障喉刘，發(fā)起高一致性主備切換流程
監(jiān)控各個set的CPU饱搏、磁盤容量、各個表的資源消耗情況券坞，必要的時候自動發(fā)起擴(kuò)容流程
Scheduler自身的容災(zāi)通過ZooKeeper的選舉機(jī)制完成恨锚，保證中心控制節(jié)點(diǎn)無單點(diǎn)猴伶。

Agent模塊負(fù)責(zé)監(jiān)控本機(jī)MySQL實(shí)例的運(yùn)行情況他挎，主要功能包括：

用短連接的方式周期性訪問本機(jī)的MySQL實(shí)例办桨，檢測是否可讀、可寫损姜，若發(fā)生異常摧阅，會將異常信息上報到ZooKeeper棒卷，最終會由上面描述的Scheduler模塊檢測到這個異常情況娇跟，從而發(fā)起容災(zāi)切換苞俘；
檢測主備復(fù)制的執(zhí)行情況吃谣，會定期上報主備復(fù)制的延時和延遲的事務(wù)數(shù)岗憋，若發(fā)生了主備切換仔戈，自動向新主機(jī)重建主備晋修，因此MySQL的主備不需要DBA干預(yù)墓卦，對于新增的實(shí)例會自動采用xtrabackup通過主機(jī)自動重建數(shù)據(jù)落剪；
檢測MySQL實(shí)例的CPU利用率和各個表的請求量忠怖、數(shù)據(jù)量脑又、CPU利用率问麸，上報到ZooKeeper，ZooKeeper通過全局的資源情況抉擇如何擴(kuò)容棱烂、縮容粪糙；
監(jiān)控是否有下發(fā)到自身的擴(kuò)容任務(wù)，如有則會執(zhí)行擴(kuò)容流程；
監(jiān)控是否要發(fā)生容災(zāi)切換项阴，并按計劃執(zhí)行主備切換流程环揽。

網(wǎng)關(guān)基于MySQL Proxy開發(fā)庵佣，在網(wǎng)絡(luò)層巴粪、連接管理、SQL解析衡创、路由等方面做了大量優(yōu)化璃氢，主要特點(diǎn)和功能如下：

解析SQL一也，將識別出的DDL語句直接存到ZooKeeper椰苟，讓Scheduler來統(tǒng)一調(diào)度舆蝴；
Watch ZooKeeper的路由信息洁仗，拉取最新的路由表保存到本地文件和內(nèi)存赠潦；
將SQL請求路由到對應(yīng)的set她奥，支持讀寫分離哩俭；
對接入的IP拳恋、用戶名诅岩、密碼進(jìn)行鑒權(quán)鸳谜；
記錄完整的SQL執(zhí)行信息式廷，與秒級監(jiān)控平臺對接完成實(shí)時的SQL請求的時耗，成功率等指標(biāo)監(jiān)控分析袜爪；
對count辛馆、distinct昙篙、sum苔可、avg焚辅、max同蜻、min倔毙、order by、group by等聚合類SQL一般需要訪問后端的多個set卵蛉，網(wǎng)關(guān)會分析結(jié)果并做合并再返回傻丝，暫不支持跨set join和分布式事務(wù)葡缰；
網(wǎng)關(guān)無狀態(tài)，既支持與業(yè)務(wù)部署到一起温算，也可以獨(dú)立部署（可通過TGW或者LVS做容災(zāi)）注竿。

分表邏輯

在TDSQL中，每個表（邏輯表）可能會拆分成多個子表（建表的時候通過在建表語句中嵌入注釋的方式提供一個shard字段名付燥，最多會拆分出多個子表）键科，每個子表在MySQL上都是一個真實(shí)的物理表萝嘁，這里稱為一個shard，分布在某個set中怪得，因此一張表的數(shù)據(jù)可能會按這樣的方式分布在多個Set中徒恋，如下圖：

每個SQL請求到達(dá)網(wǎng)關(guān)之后，網(wǎng)關(guān)會做詞法和語法解析硝拧，重點(diǎn)會解析出shard字段障陶，如果帶了shard字段就可以直接查詢路由表并發(fā)送到某個具體的set中抱究。計費(fèi)的OLTP類業(yè)務(wù)99%的請求都會帶上shard字段勋拟；如果某筆請求沒有shard字段，查詢路由之后會將請求發(fā)送到所有的shard對應(yīng)的set中敢靡，并對所有返回的結(jié)果做一些聚合運(yùn)算杂彭。

分片方式比較

TABLE SHARD：

GROUP SHARD特點(diǎn)：邏輯A亲怠、B团秽、C表中具有同樣的shard id的數(shù)據(jù)分布到同個set中习勤。

目前TDSQL在騰訊云上暫時只支持單SET模式，GROUP SHARD模式也會很快上線眷唉。

容災(zāi)機(jī)制

對于TDSQL來說蛤虐，我們希望容災(zāi)做到自動切換驳庭，自動恢復(fù)饲常，主備一致性（保證業(yè)務(wù)提交的事務(wù)在切換過程不丟失），跨IDC容災(zāi)霹娄。

對于TDSQL來說鲫骗，我們希望容災(zāi)做到自動切換犬耻，自動恢復(fù)，主備一致性（保證業(yè)務(wù)提交的事務(wù)在切換過程不丟失）执泰，跨IDC容災(zāi)枕磁。

對比下MYSQL的一些方案：

MySQL異步復(fù)制：

在MySQL發(fā)展的早期，就提供了異步復(fù)制的技術(shù)术吝，只要寫的壓力不是特別大计济，在網(wǎng)絡(luò)條件較好的情況下茸苇，發(fā)生主備切換基本上能將影響控制到秒級別，因此吸引了很多開發(fā)者的關(guān)注和使用沦寂。但這套方案提供的一致性保證，對于計費(fèi)或者金融行業(yè)是不夠的。
MySQL半同步復(fù)制：

到了MySQL 5.5版本的時候，Google提供了一個半同步半異步的插件试幽，確保必須收到一個備機(jī)的應(yīng)答才讓事務(wù)在主機(jī)中提交；當(dāng)備機(jī)應(yīng)答超時的情況下，強(qiáng)同步就會自動退化成異步模式（這也是半同步半異步名字的由來）；

下圖是二者的比較：

半同步復(fù)制可保障一致性颖御，但是：

超時后蛻化成異步芦岂，金融場景不合適
跨IDC的情況下性能不容樂觀

半同步性能不好的原因分析：

不管是模型一還是模型二呛占，每次執(zhí)行SQL走贪，都要先寫binlog，然后往從機(jī)同步binlog凯亮，等待從機(jī)應(yīng)答富拗，然后再返回給client應(yīng)答。雖然是多個線程，但執(zhí)行流是同步的戒良，CPU利用不起來某抓。

TDSQL的線程異步化改造

上半部分：任務(wù)執(zhí)行到寫binlog為止，然后將會話保存到session中，接著執(zhí)行下一輪循環(huán)去處理其他請求了秘通，這樣就避免讓線程阻塞等待應(yīng)答了；
然后：MySQL自身負(fù)責(zé)主備同步的dump線程會將binlog立即發(fā)送出去，備機(jī)的IO線程收到binlog并寫入到relay log之后庸诱，再通過UDP給主機(jī)一個應(yīng)答盗扒；
在主機(jī)上淋叶，開一組線程來處理應(yīng)答，收到應(yīng)答之后找到對應(yīng)的會話宠页，執(zhí)行下半部分的commit，send應(yīng)答备闲，綁定到epoll等操作狱掂。綁定到epoll之后這個連接又可以被其他線程檢測到并執(zhí)行了。

效果：

數(shù)據(jù)高可用性保障機(jī)制

主備自動切換

上面的強(qiáng)同步還有點(diǎn)小缺陷：比如主機(jī)用kill -9殺掉，那么可能寫了binlog但沒有來得及發(fā)送到遠(yuǎn)端抡蛙，此時當(dāng)然也不會返回給業(yè)務(wù)成功，備機(jī)上不存在這筆數(shù)據(jù)蜂奸，但主機(jī)起來之后會多出來這筆事務(wù)。我們的做法是對新增的事務(wù)根據(jù)row格式的binlog做閃回，當(dāng)然回退不了的比如drop table之類的植阴，就直接提醒運(yùn)維手工確認(rèn)是保留還是清除數(shù)據(jù)庫掠手，然后會由Xtrabakcup機(jī)制自動從新的備機(jī)全量拉取數(shù)據(jù)重構(gòu)报腔。

靈活的主備配置

通常為了保證可用性纵隔，TDSQL最少要求一主二從分布在3個IDC的部署方式俄认，保證任意一個IDC掛掉都不影響系統(tǒng)的可用性和數(shù)據(jù)一致性卸伞。2個IDC同時掛掉，系統(tǒng)還可以提供只讀服務(wù)乌询。當(dāng)然業(yè)務(wù)可以根據(jù)自身需要增加更多的從節(jié)點(diǎn)榜贴，同時可以選擇性的將讀請求分到從機(jī)，進(jìn)一步提高系統(tǒng)的可用性和處理能力妹田。甚至可以選擇增加異地的災(zāi)備節(jié)點(diǎn)（通常采用異步的方式）唬党，提供跨城容災(zāi)的能力。

TDSQL應(yīng)用

目前TDSQL已經(jīng)在騰訊云官網(wǎng)對外開放售賣鬼佣；

完善的帳號和權(quán)限管理：

為了更好的控制風(fēng)險驶拱，TDSQL默認(rèn)不提供超級用戶，也無法直接通過SQL語句進(jìn)行帳號和權(quán)限管理晶衷。響應(yīng)的蓝纲，在WEB管理頁面，有非常方便的管理模塊：

上圖是帳號列表晌纫，點(diǎn)擊左上按鈕可以新建用戶税迷，指定用戶名和主機(jī)，主機(jī)支持%這樣的匹配方式锹漱，點(diǎn)擊克隆帳號可以完全復(fù)制當(dāng)前帳號的權(quán)限來新建一個帳號箭养。

點(diǎn)擊修改權(quán)限，如下圖：

可以看到哥牍，通過左邊的導(dǎo)航欄毕泌，提供了完全兼容mysql管理方式的圖形化界面，權(quán)限管理可以細(xì)化到列級砂心。（圖中因?yàn)槭窍到y(tǒng)表懈词，所以只提供SELECT權(quán)限的授權(quán)）。

支持批量設(shè)置參數(shù)

高效便捷的數(shù)據(jù)庫參數(shù)設(shè)置：

支持查看參數(shù)修改歷史記錄：

慢查詢分析

下圖是按時間段列出的不同慢查詢（抽象后的）的列表：

下圖是某條慢查詢（抽象后的）詳細(xì)統(tǒng)計數(shù)據(jù)：

此處輸入圖片的描述

操作日志辩诞，記錄60天內(nèi)所有相關(guān)管理操作記錄：