分布式數(shù)據(jù)庫TDSQL架構(gòu)原理概述

1、 Page * MERGEFORMAT 43騰訊分布式數(shù)據(jù)庫TDSQL金融級(jí)能力的架構(gòu)原理概述目錄TDSQL是什么：騰訊如何打造一款金融級(jí)分布式數(shù)據(jù)庫我們先初步了解TDSQL產(chǎn)品，以及它的適用場景。第一章包括四個(gè)方面：使用場景、發(fā)展歷程、核心特性，以及兼容性。首先，TDSQL是騰訊推出的一款兼容MySQL的自主可控、高一致性分布式數(shù)據(jù)庫產(chǎn)品。這里我們強(qiáng)調(diào)一點(diǎn)，高度兼容MySQLTDSQL完全兼容MySQL協(xié)議，并且做到完全自主可控、數(shù)據(jù)強(qiáng)一致性。第二是TDSQL具備分布式的特性，具備一個(gè)彈性擴(kuò)展、高可用的架構(gòu)。在互聯(lián)網(wǎng)行業(yè)，海量的用戶流量場景很常見，如果數(shù)據(jù)庫不具備可伸縮性、可擴(kuò)展性，是很難應(yīng)

2、對(duì)如：電商的大型促銷，春節(jié)搶紅包等突增流量的場景，這些其實(shí)都是對(duì)數(shù)據(jù)庫應(yīng)對(duì)海量用戶流量的考驗(yàn)。目前TDSQL已經(jīng)服務(wù)超過500+的金融政企，行業(yè)覆蓋銀行、保險(xiǎn)、證券、政務(wù)、互聯(lián)網(wǎng)金融等各個(gè)領(lǐng)域。我們?cè)倏匆幌耇DSQL的前世今生。TDSQL最早可以追溯到2002年，那個(gè)時(shí)候其實(shí)還不叫TDSQL，它是騰訊計(jì)費(fèi)平臺(tái)部的一個(gè)數(shù)據(jù)庫服務(wù)，當(dāng)時(shí)使用了開源的MySQL。2002年-2007年隨著公司業(yè)務(wù)的發(fā)展，騰訊所面臨的用戶量的壓力也越來越大。這個(gè)時(shí)候我們提出了724小時(shí)不宕機(jī)的高可用設(shè)計(jì)方案，來保證數(shù)據(jù)庫能提供724小時(shí)不間斷連續(xù)高可用服務(wù)。那個(gè)時(shí)候，騰訊的增值業(yè)務(wù)日漸成規(guī)模，業(yè)務(wù)對(duì)數(shù)據(jù)也越來越敏感，對(duì)

3、數(shù)據(jù)可用性的要求越來越高，甚至平時(shí)還要防備一些像運(yùn)營商的光纖被挖斷等各種各樣的異常場景。在2007年-2012年，這可能是互聯(lián)網(wǎng)時(shí)代從互聯(lián)網(wǎng)到移動(dòng)互聯(lián)網(wǎng)的發(fā)展的快速5年。當(dāng)然，公司的業(yè)務(wù)也是突飛猛進(jìn)。我們開始把這個(gè)高可用的數(shù)據(jù)庫產(chǎn)品化。到2012年，TDSQL的雛形就已經(jīng)出來了，作為一款內(nèi)部產(chǎn)品，開始在公司內(nèi)部提供金融級(jí)的數(shù)據(jù)強(qiáng)一致性、可靠性服務(wù)。從2012年起，TDSQL已經(jīng)在騰訊內(nèi)部做得已經(jīng)比較成熟，已經(jīng)是一個(gè)知名的產(chǎn)品了，但是它一直沒有對(duì)外做商業(yè)化。2014年恰逢一個(gè)很好的機(jī)會(huì)微眾銀行的成立。微眾銀行做數(shù)據(jù)庫選型的時(shí)候關(guān)注到了TDSQL，經(jīng)過反復(fù)測試驗(yàn)證，發(fā)現(xiàn)當(dāng)時(shí)的TDSQL已經(jīng)完全具備

4、了微眾銀行對(duì)數(shù)據(jù)可用性和一致性的要求。借此機(jī)會(huì)，TDSQL成功在微眾銀行投產(chǎn)，成為微眾銀行唯一的數(shù)據(jù)庫，覆蓋了銀行的核心業(yè)務(wù)。所以說2014年，TDSQL完成了商業(yè)化，也實(shí)現(xiàn)了私有化部署。2014年以后，TDSQL推廣到了很多銀行、金融機(jī)構(gòu)，這過程中是借鑒了2014年TDSQL在微眾銀行成功實(shí)施的寶貴的經(jīng)驗(yàn)。因?yàn)樵?014年微眾銀行的部署中，我們也踩了很多坑，也認(rèn)識(shí)到在私有化部署環(huán)境的各種各樣的挑戰(zhàn)，并一一攻克了這些挑戰(zhàn)。當(dāng)2014年在私有化部署完成之后，再到2015年TDSQL上公有云，我們繼續(xù)通過公有云服務(wù)打磨自己的產(chǎn)品。所以從2012年作為一個(gè)內(nèi)部產(chǎn)品到2014年的私有化部署，再到201

5、5年公有云上的部署，TDSQL已經(jīng)逐步從一個(gè)內(nèi)部產(chǎn)品逐漸走向行業(yè)，成為一個(gè)正式對(duì)外的商用數(shù)據(jù)庫。從2015年到2019年，TDSQL已經(jīng)推廣到許多銀行和金融政企。但是很重要的一點(diǎn)是，雖然服務(wù)了很多銀行、金融客戶，但是在銀行領(lǐng)域有一塊比較難動(dòng)的蛋糕叫銀行的傳統(tǒng)核心系統(tǒng)。傳統(tǒng)核心系統(tǒng)數(shù)據(jù)庫長期以來一直是被國外的商用數(shù)據(jù)庫所壟斷，比如說ORACLE、DB2啊，像TDSQL這類分布式數(shù)據(jù)庫是很難介入的。2018年，我們關(guān)注到張家港銀行有更換核心系統(tǒng)的需求，就此建立聯(lián)系并成功達(dá)成合作，最終，2019年，我們將騰訊這套分布式數(shù)據(jù)庫系統(tǒng)成功應(yīng)用到了張家港銀行的傳統(tǒng)核心系統(tǒng)。張家港行也是作為全國第一家傳統(tǒng)核心

6、系統(tǒng)上分布式數(shù)據(jù)庫的銀行，分布式數(shù)據(jù)庫不再是只局限于銀行的互聯(lián)網(wǎng)核心、互聯(lián)網(wǎng)銀行等外圍系統(tǒng)的嘗試，而是真真正正切入到銀行系統(tǒng)的心臟傳統(tǒng)核心，這也是國產(chǎn)數(shù)據(jù)庫領(lǐng)域一個(gè)具有里程碑意義的事件。所以在未來，我們也將繼續(xù)“走出去”深入到更復(fù)雜、更新核心的業(yè)務(wù)系統(tǒng)，打磨我們的產(chǎn)品。這是TDSQL的發(fā)展歷程。TDSQL核心特性：極具挑戰(zhàn)的“四高”服務(wù)與安全可運(yùn)維我們?cè)倏碩DSQL的核心特性。首先作為適應(yīng)于金融場景的數(shù)據(jù)庫，數(shù)據(jù)強(qiáng)一致性是立命之本，因?yàn)閿?shù)據(jù)不能丟、不能錯(cuò)。在金融場景，你沒有辦法去估量假如錯(cuò)一條數(shù)據(jù)，到底這條數(shù)據(jù)是1分錢還是1個(gè)億，所以數(shù)據(jù)強(qiáng)一致是我們最根本的一個(gè)特性。不允許丟，不允許錯(cuò)，這是對(duì)

7、數(shù)據(jù)庫起碼的要求。第二是金融級(jí)高可用。TDSQL確保99.999%以上的可用性，并支持跨IDC、多機(jī)房、同城多活的部署方式。我們最先切入金融場景是因?yàn)榻鹑趫鼍暗奶魬?zhàn)是最大的。中國金融行業(yè)受監(jiān)管要求最為苛刻，同時(shí)也對(duì)數(shù)據(jù)和業(yè)務(wù)的可用性、可靠性、一致性更是有極高的要求。我們要求99.999%的可用性，也就是說這個(gè)數(shù)據(jù)庫全年故障的時(shí)間不能超過5分鐘。第三是高性能、低成本。互聯(lián)網(wǎng)時(shí)代的企業(yè)，都是海量業(yè)務(wù)、海量機(jī)器，性能稍微提高一個(gè)10%，可能就節(jié)約成百上千臺(tái)機(jī)器的成本，這個(gè)經(jīng)濟(jì)效益還是比較大的。所以高性能、低成本也是TDSQL的一個(gè)關(guān)鍵特性。第四點(diǎn)是線性水平擴(kuò)展。因?yàn)闊o論是互聯(lián)網(wǎng)還是其他企業(yè)，隨著數(shù)字

8、化的發(fā)展，比如說出現(xiàn)突增流量，搞個(gè)活動(dòng)等，現(xiàn)在單機(jī)的承載量越來越容易凸顯出瓶頸。所以我們提出這種水平線性擴(kuò)展的能力，要求它可進(jìn)行水平伸縮。可能一臺(tái)機(jī)器的負(fù)載、硬盤、機(jī)器資源容納不了，但可以把它拆到多臺(tái)機(jī)器，不需要考慮太多，它可以自動(dòng)地提高自身吞吐量和負(fù)載量。第五點(diǎn)是企業(yè)級(jí)安全。金融數(shù)據(jù)是敏感的，一些敏感的金融數(shù)據(jù)需要在當(dāng)前數(shù)據(jù)基礎(chǔ)上再做一層更高級(jí)別的企業(yè)安全防護(hù)，比如數(shù)據(jù)庫防火墻，以及透明加密，等等。第六點(diǎn)是便捷的運(yùn)維，私有化部署中，很多情況下其實(shí)他們的網(wǎng)絡(luò)環(huán)境和部署環(huán)境跟我們是隔離的，如果銀行客戶有問題，那其實(shí)我們第一時(shí)間是切入不了去幫助解決的，所以就需要一套完善的配套設(shè)施，簡單容易上手，可

9、以自動(dòng)幫用戶去定位問題、解決問題，同時(shí)也盡量減少運(yùn)維的復(fù)雜度。TDSQL核心架構(gòu)接下來我們了解TDSQL的架構(gòu)以及模塊劃分。通過這一章節(jié)的了解，我們更能切入TDSQL的技術(shù)細(xì)節(jié)，它為什么要這樣設(shè)計(jì)，這樣設(shè)計(jì)有什么好處，如何通過這樣的架構(gòu)和設(shè)計(jì)實(shí)現(xiàn)高可用、線性擴(kuò)展等能力。TDSQL系統(tǒng)總覽資源池這張圖從下往上看，首先最底層是資源池，屬于IaaS層服務(wù)，可以是物理機(jī)，也可以是虛擬機(jī)，只要是給TDSQL添加機(jī)器就好，TDSQL是在一個(gè)機(jī)器的資源池上實(shí)現(xiàn)了數(shù)據(jù)庫實(shí)例的管理。當(dāng)然，這里推薦的還是物理機(jī)，如果增加一層虛擬機(jī)服務(wù)，無疑在穩(wěn)定性和性能方面都會(huì)引入一些隱患。存儲(chǔ)節(jié)點(diǎn)從資源池再往上是存儲(chǔ)節(jié)點(diǎn)。存儲(chǔ)

10、節(jié)點(diǎn)要強(qiáng)調(diào)的是TDSQL的兩種存儲(chǔ)形態(tài)，一種是Noshard數(shù)據(jù)庫，一種是分布式數(shù)據(jù)庫（也叫Shard版TDSQL）。簡單來說，Noshard就是一個(gè)單機(jī)版的TDSQL，在MySQL的基礎(chǔ)上做了一系列的改造和改良，讓它支持TDSQL的一系列特性，包括高可用，數(shù)據(jù)強(qiáng)一致、724小時(shí)自動(dòng)故障切換等。第二種是分布式數(shù)據(jù)庫，具備水平伸縮能力。所以TDSQL對(duì)外其實(shí)呈現(xiàn)了兩種形態(tài)，呈現(xiàn)一種非分布式形態(tài)，一種是分布式的形態(tài)。至于這兩種形態(tài)的區(qū)別，或者說什么場景更適合于哪種數(shù)據(jù)庫，后面我們有專門的章節(jié)去分析。計(jì)算節(jié)點(diǎn)再看計(jì)算節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)就是TDSQL的計(jì)算引擎，做到了計(jì)算層和存儲(chǔ)層相分離。計(jì)算層主要是做一

11、些SQL方面的處理，比如詞法解、語法解析、SQL改寫等。如果是分布式數(shù)據(jù)庫形態(tài)，還要做分布式事務(wù)相關(guān)的協(xié)調(diào)，所以我們看到計(jì)算層不存儲(chǔ)數(shù)據(jù)，只運(yùn)行SQL方面的實(shí)時(shí)計(jì)算，所以它更偏CPU密集型。此外，TDSQL計(jì)算節(jié)點(diǎn)還具備OLAP的能力，對(duì)一些復(fù)雜的計(jì)算可以進(jìn)行算法上的優(yōu)化什么時(shí)候該下推到存儲(chǔ)引擎層，什么時(shí)候需要在計(jì)算層做匯總等，這是計(jì)算節(jié)點(diǎn)需要做的事情。赤兔運(yùn)營管理平臺(tái)再往上，是赤兔運(yùn)營管理平臺(tái)，如果說把下面這一套東西比作一個(gè)黑盒，我們希望有一個(gè)用戶界面操縱這個(gè)黑盒，這個(gè)界面就是赤兔運(yùn)營管理平臺(tái)。通過這個(gè)平臺(tái)，DBA可以操縱TDSQL后臺(tái)黑盒，所以相當(dāng)于是一套WEB管理系統(tǒng)。讓所有DBA的操作

12、都可以在用戶界面上完成，而不需要登陸到后臺(tái)，不需要關(guān)心計(jì)算節(jié)點(diǎn)是哪個(gè)，存儲(chǔ)節(jié)點(diǎn)是哪個(gè)，或者怎么樣管理它，要加一些節(jié)點(diǎn)或者減一些節(jié)點(diǎn)，或者把這個(gè)節(jié)點(diǎn)從哪里要遷到哪里這些都可以通過界面化完成。DBA操作界面不容易出錯(cuò)，但如果登陸到后臺(tái)很容易一個(gè)誤操作，不小心把機(jī)器重啟了，就可能會(huì)造成一定的影響。“扁鵲”智能DBA平臺(tái)有了赤兔之外，為什么還有一個(gè)“扁鵲”智能DBA平臺(tái)呢？可能正常情況下，我們機(jī)器是好的，但是，機(jī)器如果發(fā)生了故障，或者說哪天磁盤有壞塊了，或者是IO性能越來越差SSD其實(shí)有一個(gè)衰老的過程，到了后期的話，吞吐量和IOPS可能會(huì)有一定下降，導(dǎo)致數(shù)據(jù)庫的響應(yīng)速度變慢。這種情況如果DBA要排查，

13、得先去看到是哪一個(gè)實(shí)例、涉及到哪一臺(tái)機(jī)器、這個(gè)機(jī)器有什么問題、檢測機(jī)器的健康狀態(tài)這些都是機(jī)械性的工作，有了扁鵲智能管理平臺(tái)，當(dāng)出現(xiàn)故障的時(shí)候就可以自動(dòng)分析故障的原因，舉個(gè)例子，可以找出是因?yàn)槭裁磳?dǎo)致SQL變慢了，或者又是因?yàn)槭裁丛虬l(fā)生了主備切換，突然IO異常了或者其他什么原因?qū)е聶C(jī)器故障。此外，扁鵲智能DBA平臺(tái)還有一個(gè)智能診斷系統(tǒng)，可以定期由DBA發(fā)起對(duì)實(shí)例進(jìn)行的診斷。比如有些數(shù)據(jù)庫實(shí)例，CPU常年跑得很高，其實(shí)是一些比較差的SQL導(dǎo)致的。這個(gè)時(shí)候扁鵲智能DBA系統(tǒng)，可以很方便地到用戶實(shí)例上做巡檢，得到一個(gè)健康狀況圖，并對(duì)它進(jìn)行打分，發(fā)現(xiàn)這個(gè)實(shí)例比如他的CPU超用了，需要擴(kuò)容，但是沒有擴(kuò)容

14、，就會(huì)減分；然后其他表的索引沒有建好，要減分以此生成一個(gè)診斷報(bào)告。所以，有了扁鵲，再加上赤兔運(yùn)營管理平臺(tái)，DBA的工作其實(shí)是非常輕松的，可能每天只需要點(diǎn)幾下按紐，然后就解決了一系列的麻煩，包括高可用，性能分析，鎖分析等，完全把DBA從繁雜的工作中解放出來。此外，我們看到這里其實(shí)還有幾個(gè)小的模塊。調(diào)度系統(tǒng)，調(diào)度系統(tǒng)主要是負(fù)責(zé)整體的資源調(diào)度，比如說數(shù)據(jù)庫實(shí)例的增加刪除、過期作廢，還有一些容量的調(diào)度，即擴(kuò)容、縮容，還有一些多租戶的管理。也就是說這是整個(gè)管理臺(tái)的調(diào)度器。另外還有一個(gè)備份系統(tǒng)，這個(gè)是冷備中心，后面有一個(gè)專門的章節(jié)去講，這里就不再贅述。此外，我們還提供了一些服務(wù)模塊作為輔助，比如審計(jì)，還有

15、數(shù)據(jù)庫之間的遷移服務(wù)我們TDSQL怎么能夠幫助異地?cái)?shù)據(jù)庫遷進(jìn)來，或者從TDSQL再遷出。此外，還包括數(shù)據(jù)校驗(yàn)、數(shù)據(jù)訂閱、SQL防火墻、注入檢測等安全方面的模塊，以及一個(gè)輔助模塊幫助我們的DBA也好，用戶也好，完成一些個(gè)性化的豐富的需求。以上是TDSQL系統(tǒng)總覽。TDSQL架構(gòu)模塊及其特性我們?cè)倏匆幌潞诵募軜?gòu)。核心架構(gòu)其實(shí)是上一個(gè)圖的縮覽，我們把核心的模塊挑選出來。首先用戶的請(qǐng)求通過負(fù)載均衡發(fā)往SQL引擎。然后，SQL引擎作為計(jì)算接入層，根據(jù)這個(gè)SQL的要求從后端的存儲(chǔ)節(jié)點(diǎn)去取數(shù)據(jù)。當(dāng)然，無論是SQL引擎還是后端的數(shù)據(jù)庫實(shí)例都存在一個(gè)元數(shù)據(jù)來管理調(diào)度。舉個(gè)例子，計(jì)算引擎需要拿到一個(gè)路由，路由告訴

16、SQL引擎，這個(gè)SQL該發(fā)往哪一個(gè)后端的數(shù)據(jù)節(jié)點(diǎn)，到底是該發(fā)往主節(jié)點(diǎn)還是發(fā)往備節(jié)點(diǎn)。所以我們引入了ZK（Zookeeper）來儲(chǔ)存類似于路由這類元數(shù)據(jù)信息。當(dāng)然ZK只是靜態(tài)的存儲(chǔ)元數(shù)據(jù)，維護(hù)和管理這些元數(shù)據(jù)信息，還需要有一套調(diào)度以及接口組件，這里是OSS、Manager/Schedule。所以我們這張圖可以看到是TDSQL整體來說就分為三部分：管理節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)。當(dāng)然這里還有一個(gè)輔助模塊，幫助完成一些個(gè)性化需求的，比如備份、消息隊(duì)列，數(shù)據(jù)遷移工具等。另外，這里的負(fù)載均衡其實(shí)不是必需的，用戶可以選用自身的硬件負(fù)載，也可以用LVS軟負(fù)載，這個(gè)負(fù)載均衡根據(jù)實(shí)際的用戶場景可自定義。了解了整體

17、架構(gòu)以后，我們繼續(xù)再看一下每個(gè)節(jié)點(diǎn)的特性是什么、對(duì)機(jī)器的依賴程度如何，要求機(jī)器有哪些特性，等等。管理模塊：輕松通過web界面管理整個(gè)數(shù)據(jù)庫后臺(tái)首先，我們要看的是管理模塊。作為一個(gè)集群只搭建一套的管理模塊，一般可以復(fù)用一組機(jī)器。同時(shí)，管理模塊對(duì)機(jī)器的要求相對(duì)來說比較低，比如資源緊張的時(shí)候，我們用虛擬機(jī)就可以代替。在我們內(nèi)部，一套管理模塊承載最大的管理單集群近上萬實(shí)例。管理模塊包含前文說的幾個(gè)關(guān)鍵模塊：Zookeeper(ZK)、Scheduler、Manager、OSS和監(jiān)控采集程序、赤兔管理控制臺(tái)。那么它們是怎么聯(lián)合工作的呢？首先，DBA用戶在赤兔管理臺(tái)這一套WEB前臺(tái)發(fā)起一個(gè)操作點(diǎn)了一個(gè)按紐

18、，這個(gè)按紐可能是對(duì)實(shí)例進(jìn)行擴(kuò)容，這個(gè)按紐會(huì)把這個(gè)https的請(qǐng)求轉(zhuǎn)移到OSS模塊，這個(gè)OSS模塊有點(diǎn)像web服務(wù)器，它能接收web請(qǐng)求，但是它可以把這個(gè)轉(zhuǎn)發(fā)到ZK。所以，OSS模塊就是一個(gè)前端到后臺(tái)的橋梁，有了OSS模塊，整個(gè)后臺(tái)的工作模塊都可以跟前臺(tái)、跟web界面綁定在一起。好，捕捉到這個(gè)請(qǐng)求之后，在ZK上創(chuàng)建一個(gè)任務(wù)節(jié)點(diǎn)，這個(gè)任務(wù)節(jié)點(diǎn)被調(diào)度模塊捕獲，捕獲之后就處理任務(wù)。處理完任務(wù)，再把它的處理結(jié)果返回到ZK上。ZK上的任務(wù)被OSS捕獲，最后也是https的請(qǐng)求，去查詢這個(gè)任務(wù)，最后得到一個(gè)結(jié)果，返回給前端。這是一個(gè)純異步的過程，但是有了這套管理模塊，讓我們可以輕松的通過web界面去管理整個(gè)

19、TDSQL的后臺(tái)。當(dāng)然，這整個(gè)過程都有一個(gè)監(jiān)控采集模塊去采集，對(duì)整個(gè)流程的審計(jì)及狀態(tài)進(jìn)行獲取。DB模塊：數(shù)據(jù)庫無損升級(jí)DB模塊，即數(shù)據(jù)節(jié)點(diǎn)，數(shù)據(jù)存取服務(wù)屬于IO密集型的服務(wù)，因此，數(shù)據(jù)節(jié)點(diǎn)也是我們的存儲(chǔ)節(jié)點(diǎn)，它對(duì)IO的要求比較高，一般建議配置SSD硬盤，最好是PCI-E的SSD。因?yàn)閷?duì)數(shù)據(jù)庫服務(wù)來說，CPU再高，如果IO跟不上，仍然是小馬拉大車。比如只有1千的IOPS，CPU根本就跑不起來，用不起來。所以這里一般建議至少IOPS要達(dá)到1萬以上。我們?cè)倏匆幌耂ET的概念。SET就是數(shù)據(jù)庫實(shí)例，一個(gè)SET包含數(shù)據(jù)庫的比如我們默認(rèn)要求的是一主兩備，一個(gè)Master節(jié)點(diǎn)和兩個(gè)Slave節(jié)點(diǎn)。當(dāng)然在DB

20、節(jié)點(diǎn)上有一個(gè)Agent的模塊。MySQL在執(zhí)行中，我們要監(jiān)控它的行為，以及進(jìn)行操作。如果把這些東西做到MySQL里面為什么不可以呢？這其實(shí)存在一個(gè)問題，如果對(duì)數(shù)據(jù)節(jié)點(diǎn)進(jìn)行升級(jí)，可能就要涉及到重啟，一旦重啟就影響用戶的業(yè)務(wù)，影響服務(wù)。這個(gè)時(shí)候我們就考慮，在它上面加一個(gè)模塊Agent，它來完成對(duì)所有集群對(duì)MySQL的操作，并且上報(bào)MySQL的狀態(tài)。有了它之后，對(duì)TDSQL數(shù)據(jù)節(jié)點(diǎn)的大部分升級(jí)，都會(huì)轉(zhuǎn)變?yōu)閷?duì)Agent的升級(jí)，而升級(jí)Agent，對(duì)業(yè)務(wù)沒有任何影響，這就實(shí)現(xiàn)了無損升級(jí)。相比于Agent我們對(duì)數(shù)據(jù)節(jié)點(diǎn)MySQL不會(huì)頻繁升級(jí)，一般情況下一年、半年都不會(huì)動(dòng)它。這是我們DB模塊，也是存儲(chǔ)節(jié)點(diǎn)。S

21、QL引擎模塊：分布式復(fù)雜SQL處理接下來再看另外一個(gè)比較重要的模塊：SQL引擎模塊。SQL引擎處于計(jì)算層的位置，本身屬于CPU密集型，所以我們?cè)谶x機(jī)型上盡量要求CPU高一些。其次是內(nèi)存，作為計(jì)算接入層，它要管理鏈接，如果是大量的短鏈接或者長鏈接，非常占內(nèi)存，所以它對(duì)CPU和內(nèi)存的要求比較高。此外，它本身不存儲(chǔ)數(shù)據(jù)，也沒有主備之分，所以對(duì)硬盤沒有太大要求。我們看一下SQL引擎的特性。SQL引擎首先還是從ZK上拉取到元數(shù)據(jù)，作為SQL引擎，包括權(quán)限校驗(yàn)、讀寫分離，以及統(tǒng)計(jì)信息、協(xié)議模擬等相關(guān)的操作?？赡苡行┤藭?huì)問，其實(shí)這個(gè)SQL引擎豈不是一種中間件？其實(shí)并不是這樣，SQL引擎如果是一個(gè)中間件，它都

22、可以脫離MySQL。但是我們這個(gè)SQL引擎，需要做詞法、語法分析，以及作為查詢引擎等工作。而且在分布式的場景下，SQL引擎復(fù)雜的功能性就會(huì)凸顯，比如要處理分布式事物，還要維護(hù)全局自增字段，保證多個(gè)數(shù)據(jù)、多個(gè)存儲(chǔ)節(jié)點(diǎn)共享一個(gè)保證全局自增的序列；如果是分布式的話，要限制一些語法，包括詞法和語法的解析；還有在一些復(fù)雜計(jì)算上，它還要做一些SQL下推，以及最后數(shù)據(jù)的聚合。所以SQL引擎還是一個(gè)相對(duì)來說比較復(fù)雜的模塊，作為計(jì)算層，并不是一個(gè)簡單的中間件那么簡單。這就是一個(gè)SQL引擎。TDSQL金融級(jí)特性之：數(shù)據(jù)強(qiáng)一致性保障前面我們了解了TDSQL的整體架構(gòu)和核心特性。接下來我們要重點(diǎn)聊一聊它最重要的特性作

23、為金融場景下不可或缺的數(shù)據(jù)強(qiáng)一致性的保障。我們將從四個(gè)方面來聊一聊數(shù)據(jù)一致性的保障：主備數(shù)據(jù)復(fù)制方式數(shù)據(jù)復(fù)制比較：TDSQL主備數(shù)據(jù)復(fù)制方案 VS MySQL原生方案核心功能：容災(zāi)切換，數(shù)據(jù)強(qiáng)一致、0丟失0出錯(cuò)數(shù)據(jù)強(qiáng)一致性TDSQL主備數(shù)據(jù)復(fù)制：高性能強(qiáng)同步首先在講數(shù)據(jù)一致性之前，我們先了解一下MySQL原生的數(shù)據(jù)復(fù)制的方式。首先第一種是異步復(fù)制：主機(jī)在不等從機(jī)應(yīng)答直接返回客戶端成功。這個(gè)在金融場景是不能接受的，這樣的話相當(dāng)于數(shù)據(jù)是沒有多副本保障。第二種是半同步：主機(jī)在一定條件下等備機(jī)應(yīng)答，如果等不到備機(jī)應(yīng)答，它還是會(huì)返回業(yè)務(wù)成功，也就是說它最終還會(huì)退化成一個(gè)異步的方式，這同樣也是金融場景所不

24、能接受的。除此之外，原生半同步其實(shí)是有一個(gè)性能方面的缺陷，即在跨IDC網(wǎng)絡(luò)抖動(dòng)的場景下，請(qǐng)求毛刺現(xiàn)象很嚴(yán)重。所以原生的異步復(fù)制和半同步復(fù)制都存在一些問題，并不能完全適應(yīng)金融場景。TDSQL引入了基于raft協(xié)議的強(qiáng)同步復(fù)制，主機(jī)接收到業(yè)務(wù)請(qǐng)求后，等待其中一個(gè)備機(jī)應(yīng)答成功后才返回客戶端成功。比如這張圖，我們一主兩備下一條業(yè)務(wù)請(qǐng)求到達(dá)了主機(jī)之后必須等其中一個(gè)備機(jī)應(yīng)答成功，才能返回客戶端成功，否則這個(gè)請(qǐng)求是不會(huì)應(yīng)答的。所以說，強(qiáng)同步是TDSQL最基礎(chǔ)的一個(gè)特性，是TDSQL保證數(shù)據(jù)不會(huì)丟、不會(huì)錯(cuò)的關(guān)鍵。講到這里的話，可能有些同學(xué)會(huì)問，你們這個(gè)強(qiáng)同步其實(shí)也不復(fù)雜，不就是在半同步的基礎(chǔ)上把這個(gè)超時(shí)時(shí)間改

25、成無限大同時(shí)應(yīng)答的備機(jī)設(shè)置為1。并不是這樣的，TDSQL強(qiáng)同步這里的關(guān)鍵不是在解決備機(jī)應(yīng)答的問題，而是要解決這種增加了等待備機(jī)的機(jī)制之后，如何能保證高性能、高可靠性。換句話說，如果在原生半同步的基礎(chǔ)上不改造性能，僅把超時(shí)時(shí)間改成無限大的時(shí)候，其實(shí)跑出來的性能和異步比甚至連異步的一半都達(dá)不到。這個(gè)在我們看來也是無法接受的。相當(dāng)于為了數(shù)據(jù)的一致性犧牲了很大一部分性能。TDSQL強(qiáng)同步復(fù)制的性能是在原生半同步的基礎(chǔ)上做了大量的優(yōu)化和改進(jìn)，使得性能基本接近于異步。所以這里強(qiáng)同步強(qiáng)調(diào)的是，實(shí)現(xiàn)強(qiáng)同步的同時(shí)還具備高性能特性，所以確切地說是一個(gè)高性能的強(qiáng)同步。那么我們?nèi)绾螌?shí)現(xiàn)高性能的強(qiáng)同步？我們繼續(xù)往下看。

26、這里TDSQL對(duì)MySQL主備復(fù)制的機(jī)制做了改造。首先，我們先引入了一個(gè)線程池的模型。原生的MySQL是一個(gè)互聯(lián)請(qǐng)求是一個(gè)線程，這樣對(duì)操作系統(tǒng)的資源消耗還是很大的：5千個(gè)連接，5千個(gè)線程。那1萬個(gè)連接，1萬個(gè)線程，操作系統(tǒng)能扛得住嗎？肯定扛不住。而且原生的數(shù)據(jù)復(fù)制的方式，其實(shí)串行化比較高，比如說一個(gè)用戶請(qǐng)求發(fā)過來后，等備機(jī)應(yīng)答；這個(gè)過程中用戶線程在這里是完全不能做事的，只有等備機(jī)應(yīng)答之后，它才能夠返回前端。也就是說大量的線程都處于一個(gè)等待的狀態(tài)，這是半同步效率低的根本原因。引入了線程池模型之后，我們還需要考慮怎么調(diào)度線程池。我們希望MySQL維護(hù)一小部分工作的線程，比如說有1萬個(gè)用戶連接，真正

27、干活的可能就那么100個(gè)、50個(gè)MySQL的工作線程。如果是非工作的線程，他在等IO應(yīng)答時(shí)可以先去睡眠，并不讓它去影響我們的吞吐量。所以TDSQL對(duì)原生的復(fù)制做了改造，除了引入線程池模型，還增加了幾組自定義的線程。這個(gè)線程是做什么呢？當(dāng)一筆用戶請(qǐng)求過來之后完成了寫操作以及刷新了binlog，第二步他應(yīng)該要等備機(jī)應(yīng)答。這個(gè)時(shí)候被我們新引入的線程組所接管，把這個(gè)用戶對(duì)話保留下來，釋放了工作線程，工作線程該干什么繼續(xù)干什么，處理其他的用戶連接請(qǐng)求。真正備機(jī)給了應(yīng)答之后，再由另外一組線程將它喚醒，回吐到客戶端，告訴客戶端這個(gè)應(yīng)答成功了。所以經(jīng)過這樣一個(gè)異步化的過程，相當(dāng)于把之前串行的流程異步化了，這樣

28、就達(dá)到了接近于異步復(fù)制的性能，這就是TDSQL在強(qiáng)同步的改造的核心。所以我們這里強(qiáng)調(diào)不單單是一個(gè)實(shí)現(xiàn)強(qiáng)同步的過程，更是一個(gè)接近異步性能的強(qiáng)同步。再看一下改造之后的性能對(duì)比：異步TPS大概是6萬左右，平均時(shí)耗小于等于10毫秒。再看半同步，明顯有三分之二的性能損耗，并且這個(gè)時(shí)耗波動(dòng)還是比較大的，比如說IDC網(wǎng)絡(luò)抖動(dòng)一下。強(qiáng)同步一主兩備模式下，首先性能已經(jīng)接近于異步的性能，此外時(shí)耗并沒有額外增加。TPS跟場景相關(guān)，數(shù)據(jù)僅提供橫向?qū)Ρ葏⒖家驗(yàn)橐恢鲀蓚?，除非兩個(gè)機(jī)房網(wǎng)絡(luò)同時(shí)抖動(dòng)，否則的話強(qiáng)同步的時(shí)耗不會(huì)有明顯波動(dòng)。所以我們看到基于TDSQL的強(qiáng)同步實(shí)現(xiàn)了數(shù)據(jù)的多副本又保證了性能。有了這個(gè)多副本保障，又怎

29、么如何實(shí)現(xiàn)故障自動(dòng)切換，數(shù)據(jù)不丟不錯(cuò)呢？這其實(shí)還是需要一套切換選舉的流程。這就引出了TDSQL的容災(zāi)切換功能。自動(dòng)容災(zāi)切換：數(shù)據(jù)強(qiáng)一致、0丟失0出錯(cuò)自動(dòng)容災(zāi)切換在有了強(qiáng)同步特性的基礎(chǔ)，就變得非常容易實(shí)現(xiàn)了。我們先看一下這個(gè)結(jié)構(gòu)圖：SQL引擎將請(qǐng)求發(fā)給主節(jié)點(diǎn)，主節(jié)點(diǎn)被兩個(gè)備機(jī)所同步，每個(gè)節(jié)點(diǎn)上都有對(duì)應(yīng)的Agent上報(bào)當(dāng)前節(jié)點(diǎn)的狀態(tài)。這時(shí)，主節(jié)點(diǎn)發(fā)生了故障被Agent覺察，上報(bào)到zk被Scheduler捕獲，然后Scheduler首先會(huì)把這個(gè)主節(jié)點(diǎn)進(jìn)行降級(jí)，把它變成Slave。也就是說此時(shí)其實(shí)整個(gè)集群里面全是Slave，沒有主節(jié)點(diǎn)。這個(gè)時(shí)候另外兩個(gè)存活的備機(jī)上報(bào)自己最新的binlog點(diǎn)，因?yàn)橛辛藦?qiáng)

30、同步的保障，另外兩個(gè)備機(jī)其中之一一定有最新的binlog，那么兩個(gè)備機(jī)分別上報(bào)自己最新的點(diǎn)后，Schedule就可以清楚的知道哪個(gè)節(jié)點(diǎn)的數(shù)據(jù)是最新的，并將這個(gè)最新的節(jié)點(diǎn)提升成主節(jié)點(diǎn)。比如說發(fā)現(xiàn)Slave1的數(shù)據(jù)是最新的，這個(gè)時(shí)候Schedule修改路由，把主節(jié)點(diǎn)設(shè)置為Slave1，完成了主備的切換。有了前述這個(gè)切換機(jī)制，保證了整個(gè)切換無需人為干預(yù)，并且切換前與切換后的數(shù)據(jù)是完全一致的。這里做一個(gè)總結(jié)，正是由于強(qiáng)同步的保證，所以當(dāng)主機(jī)發(fā)生故障的時(shí)候，我們一定是可以從一個(gè)備節(jié)點(diǎn)上找到最新數(shù)據(jù)，把它提成主節(jié)點(diǎn)。這就是TDSQL容災(zāi)切換的整個(gè)過程，容災(zāi)切換需要建立在強(qiáng)同步的基礎(chǔ)上。極端場景下的數(shù)據(jù)一致

31、性保障聊完了容災(zāi)切換，我們?cè)倭囊涣墓收瞎?jié)點(diǎn)的后續(xù)處理事宜。故障處理可能有幾種情況：一種是故障以后，它還能活過來。比如說像機(jī)房可能突然掉電了，掉完電之后它馬上又恢復(fù)?；蛘邫C(jī)器因?yàn)橛布虿恍⌒陌l(fā)生了重啟，重啟完之后節(jié)點(diǎn)是可以被拉起，被拉起之后，我們希望它能夠迅速的再加入到集群中，這時(shí)數(shù)據(jù)其實(shí)是沒有丟沒有錯(cuò)的，我們不希望把節(jié)點(diǎn)故障之后又重新建一份數(shù)據(jù)，把之前的數(shù)據(jù)全抹掉。而是從它最后一次同步的數(shù)據(jù)為斷點(diǎn)，繼續(xù)續(xù)傳后面的數(shù)據(jù)。帶著上述問題，我們看一下節(jié)點(diǎn)的故障后恢復(fù)過程。首先我們考慮一種場景，比如說A節(jié)點(diǎn)作為主節(jié)點(diǎn)，B、C是從，正常去同步A節(jié)點(diǎn)的數(shù)據(jù)，A+1、A+2，接下來該同步A+3。當(dāng)A+3還沒

32、有同步到從節(jié)點(diǎn)的時(shí)候發(fā)生了故障，這個(gè)時(shí)候根據(jù)B、C節(jié)點(diǎn)的數(shù)據(jù)情況，C的數(shù)據(jù)是最新的，因此C被選成了主節(jié)點(diǎn)，進(jìn)而C繼續(xù)同步數(shù)據(jù)到B。過了一陣，A節(jié)點(diǎn)拉起了，可以重新加入集群。重新加入集群之后，發(fā)現(xiàn)它有一筆請(qǐng)求A+3還沒有來得及被B、C節(jié)點(diǎn)應(yīng)答，但已經(jīng)寫入到日志。這個(gè)時(shí)候其實(shí)A節(jié)點(diǎn)的數(shù)據(jù)是有問題的，我們需要把這個(gè)沒有被備機(jī)確認(rèn)的A+3的回滾掉，防止它將來再同步給其他的節(jié)點(diǎn)。所以這里強(qiáng)調(diào)的是一個(gè)數(shù)據(jù)的回退，相當(dāng)于每一個(gè)Slave新加入節(jié)點(diǎn)的時(shí)候，我們都會(huì)對(duì)它的數(shù)據(jù)進(jìn)行檢驗(yàn)，將多寫的數(shù)據(jù)回滾。當(dāng)然剛剛的假設(shè)是運(yùn)氣比較好，A節(jié)點(diǎn)還能重啟。有些時(shí)候A節(jié)點(diǎn)可能就掛了，這個(gè)機(jī)器就再也起不來了，我們需要把這個(gè)節(jié)

33、點(diǎn)換掉，即換一個(gè)新機(jī)器，比如：加一個(gè)D節(jié)點(diǎn)。我們希望它快速重建數(shù)據(jù)并且對(duì)當(dāng)前線上業(yè)務(wù)盡可能無影響。如何讓它快速去重建呢？當(dāng)然是基于物理拷貝，而且它是從備機(jī)上去拉數(shù)據(jù)，這樣它既不會(huì)對(duì)主節(jié)點(diǎn)產(chǎn)生影響，又能夠快速把數(shù)據(jù)重建好。分布式TDSQL的實(shí)踐第四部分，我們開始講分布式TDSQL的實(shí)踐。前三章我們?cè)诹腡DSQL的高可用、強(qiáng)一致。這些作為金融場景是一個(gè)必備的特性，還沒有涉及到分布式，當(dāng)涉及到分布式時(shí)就開啟了TDSQL的另外一種形態(tài)。接下來我們就聊一聊分布式TDSQL跟單節(jié)點(diǎn)的TDSQL有什么不同，以及這種分布式架構(gòu)下又是如何實(shí)現(xiàn)一系列的保障，同時(shí)如何做到對(duì)業(yè)務(wù)透明、對(duì)業(yè)務(wù)無感知。分表分表，當(dāng)在單機(jī)

34、模式下，用戶看到的一張邏輯表，其實(shí)也是一張物理表，存儲(chǔ)在一個(gè)物理節(jié)點(diǎn)（物理機(jī)）上。在分布式形態(tài)下，用戶看到的邏輯表的實(shí)際物理存儲(chǔ)可能是被打散分布到不同的物理節(jié)點(diǎn)上。所以TDSQL分表的目標(biāo)，希望做到對(duì)業(yè)務(wù)完全透明，比如業(yè)務(wù)只看到一個(gè)完整的邏輯表，他并不知道這些表其實(shí)已經(jīng)被TDSQL均勻拆分到各個(gè)物理節(jié)點(diǎn)上。比如：之前可能數(shù)據(jù)都在一臺(tái)機(jī)器上，現(xiàn)在這些數(shù)據(jù)平均分布在了5臺(tái)機(jī)器上，但用戶卻絲毫沒有覺察，這是TDSQL要實(shí)現(xiàn)的一個(gè)目標(biāo)在用戶看來是完全的一張邏輯表，實(shí)際上它是在后臺(tái)打散了的。這個(gè)表在后臺(tái)如何去打散，如何去分布呢？我們希望對(duì)用戶做到透明，做到屏蔽，讓他不關(guān)心數(shù)據(jù)分布的細(xì)節(jié)。怎么將這個(gè)數(shù)據(jù)分

35、布和打散呢？這就引出了一個(gè)概念：shardkey是TDSQL的分片關(guān)鍵字，也就是說TDSQL會(huì)根據(jù)shardkey字段將這個(gè)數(shù)據(jù)去分散。我們認(rèn)為，shardkey是一個(gè)很自然的字段，自然地通過一個(gè)字段去將數(shù)據(jù)打散。舉個(gè)例子，騰訊內(nèi)部我們喜歡用QQ號(hào)作為一個(gè)shardkey，通過QQ號(hào)自動(dòng)把數(shù)據(jù)打散，或者微信號(hào)；而一些銀行類的客戶，更喜歡用一些客戶號(hào)、身份證號(hào)以及銀行卡號(hào)，作為shardkey。也就是說通過一個(gè)字段自然而然把這個(gè)數(shù)據(jù)分散開來。我們認(rèn)為引入shardkey后并不會(huì)增加額外的工作，因?yàn)槭紫扔脩羰亲盍私庾约旱臄?shù)據(jù)的，知道自己的數(shù)據(jù)按照什么字段均勻分布最佳，同時(shí)給用戶自主選擇分片關(guān)鍵字的

36、權(quán)利，有助于從全局角度實(shí)現(xiàn)分布式數(shù)據(jù)庫的全局性能最佳。所以這里可能有些人會(huì)想，是不是主鍵是最好的或者盡可能地分散？沒錯(cuò)，確實(shí)是這樣的，作為TDSQL的分片關(guān)鍵字越分散越好，要求是主鍵或者是唯一索引的一部分。確定了這個(gè)分片關(guān)鍵字后，TDSQL就可以根據(jù)這個(gè)分片關(guān)鍵字將數(shù)據(jù)均勻分散開來。比如這張圖，我們按照一個(gè)字段做了分片之后，將1萬條數(shù)據(jù)均勻分布在了四個(gè)節(jié)點(diǎn)上。既然我們了解了shardkey是一個(gè)分片關(guān)鍵字，那怎么去使用呢？這里我們就聊聊如何去使用。舉個(gè)例子，我們創(chuàng)建了TB1這個(gè)表，這里有若干個(gè)字段，比如說ID，從這個(gè)名字上來看就應(yīng)該知道它是一個(gè)不唯一的，或者可以說是一個(gè)比較分散的值。我們看到這

37、里，以“ID”作為分配關(guān)鍵字，這樣六條數(shù)據(jù)就均勻分散到了兩個(gè)分片上。當(dāng)然，數(shù)據(jù)均勻分散之后，我們要求SQL在發(fā)往這邊的都需要帶上shardkey，也就是說發(fā)到這里之后可以根據(jù)對(duì)應(yīng)的shardkey發(fā)往對(duì)應(yīng)的分片。如果不帶這個(gè)shardkey的話，它不知道發(fā)給哪個(gè)分片，就發(fā)給了所有分片。所以強(qiáng)調(diào)通過這樣的改善，我們要求盡可能SQL要帶上shardkey。帶上shardkey的話，就實(shí)現(xiàn)了SQL的路由分發(fā)到對(duì)應(yīng)的分片。講完數(shù)據(jù)分片，我們?cè)倏匆幌聰?shù)據(jù)的拆分。水平拆分對(duì)于分布式來說，可能最初我們所有的數(shù)據(jù)都在一個(gè)節(jié)點(diǎn)上。當(dāng)一個(gè)節(jié)點(diǎn)出現(xiàn)了性能瓶頸，需要將數(shù)據(jù)拆分，這時(shí)對(duì)我們TDSQL來說非常簡單，在界面

38、上的一個(gè)按紐：即一鍵擴(kuò)容，它就可以將這個(gè)數(shù)據(jù)自動(dòng)拆分。拆分的過程也比較容易理解，其實(shí)就是一個(gè)數(shù)據(jù)的拷貝和搬遷過程，因?yàn)閿?shù)據(jù)本身是可以按照一半一半這樣的劃分的。比如最先是這么一份數(shù)據(jù)，我們需要拆成兩份，需要把它的下半部分?jǐn)?shù)據(jù)拷到另外一個(gè)節(jié)點(diǎn)上。這個(gè)原理也比較簡單，就是一個(gè)數(shù)據(jù)的拷貝，這里強(qiáng)調(diào)的是在拷貝的過程中，其實(shí)業(yè)務(wù)是不受任何影響的。最終業(yè)務(wù)只會(huì)最終有一個(gè)秒級(jí)凍結(jié)。為什么叫秒級(jí)凍結(jié)？因?yàn)?，最后一步，?shù)據(jù)分布到兩個(gè)節(jié)點(diǎn)上涉及到一個(gè)路由信息變更，比如原來的路由信息要發(fā)到這個(gè)分片，現(xiàn)在改了之后需要按照劃分，上半部分要發(fā)給一個(gè)分片，下半部分發(fā)給另一個(gè)分片。我們?cè)诟穆酚傻倪@個(gè)過程中，希望這個(gè)數(shù)據(jù)是沒有寫

39、入相對(duì)靜止的。當(dāng)然改路由也是毫秒級(jí)別完成，所以數(shù)據(jù)拆分時(shí)，真正最后對(duì)業(yè)務(wù)的影響只有不到1s，并且只有在最后改路由的凍結(jié)階段才會(huì)觸發(fā)。講完數(shù)據(jù)拆分，我們開始切入分布式里面最難解決的這個(gè)問題，分布式事務(wù)。健壯、可靠的分布式事務(wù)單節(jié)點(diǎn)的事務(wù)是很好解決的，但是在分布式場景下想解決分布式事務(wù)還是存在一定的困難性，它需要考慮各種各樣復(fù)雜的場景。其實(shí)分布式事務(wù)實(shí)現(xiàn)不難，但首要是保證它的健壯性和可靠性，能應(yīng)對(duì)各種各樣的復(fù)雜場景。比如說涉及到分布式事務(wù)的時(shí)候，有主備切換、節(jié)點(diǎn)宕機(jī)在各種容災(zāi)的測試環(huán)境下，如何保證數(shù)據(jù)總帳是平的，不會(huì)多一分錢也不會(huì)少一分錢，這是分布式事務(wù)需要考慮的。TDSQL分布式事務(wù)基于拆的標(biāo)準(zhǔn)

40、兩階段提交實(shí)現(xiàn)，這也是業(yè)內(nèi)比較通用的方法。我們看到SQL 引擎作為分布式事務(wù)的發(fā)起者，聯(lián)合各個(gè)資源節(jié)點(diǎn)共同完成分布式事務(wù)的處理。分布式事務(wù)也是根據(jù)shardkey來判斷，具體來說，對(duì)于SQL引擎讀發(fā)起一個(gè)事務(wù)，比如第一條SQL是改用戶ID為A的用戶信息表。第二條SQL是插入一個(gè)用戶ID為A的流水表，這兩張表都以用戶ID作為shardkey。我們發(fā)現(xiàn)這兩條SQL都是發(fā)往一個(gè)分片，雖然是一個(gè)開啟的事務(wù)，但是發(fā)現(xiàn)它并沒有走分布式事務(wù)，它實(shí)際還是限制在單個(gè)分片里面走了一個(gè)單節(jié)點(diǎn)的事務(wù)。當(dāng)然如果涉及到轉(zhuǎn)帳：比如從A帳戶轉(zhuǎn)到B帳戶，正好A帳戶在第一個(gè)分片，B帳戶是第二個(gè)分片，這樣就涉及到一個(gè)分布式事務(wù)，需

41、要SQL引擎完成整個(gè)分布式事務(wù)處理。分布式事務(wù)是一個(gè)去中心化的設(shè)計(jì)，無論是SQL引擎還是后端的數(shù)據(jù)節(jié)點(diǎn)，其實(shí)都是具備高可用的同時(shí)支持線性擴(kuò)展的設(shè)計(jì)。分布式事務(wù)比較復(fù)雜，單獨(dú)講的話可能能講一門課，這里面涉及的內(nèi)容非常多，比如兩級(jí)段提交過程中有哪些異常場景，失敗怎么處理，超時(shí)怎么處理，怎么樣保證事務(wù)最終的一致性等等。這里不再深入，希望有機(jī)會(huì)能單獨(dú)給大家分享這塊內(nèi)容。所以，這里只對(duì)分布式事務(wù)做一個(gè)總結(jié)，我們不再去探討它的細(xì)節(jié)：首先是基于兩階段提交，我們?cè)贛ySQL原生XA事務(wù)的基礎(chǔ)上做了大量的優(yōu)化和BUG修復(fù)。比如說原生的XA在主備切換時(shí)會(huì)發(fā)生數(shù)據(jù)不一致和丟失，TDSQL在這個(gè)基礎(chǔ)上做了大量的修復(fù)，

42、讓XA事務(wù)能夠保證數(shù)據(jù)一致性。第二個(gè)是強(qiáng)勁的性能。起初我們引進(jìn)原生分布式事務(wù)的時(shí)候，分布式事務(wù)的性能還達(dá)不到單節(jié)點(diǎn)的一半。當(dāng)然經(jīng)過一系列的優(yōu)化調(diào)優(yōu)，最后我們的性能損耗是25%，也就是說它能達(dá)到單節(jié)點(diǎn)75%的性能。第三個(gè)是對(duì)業(yè)務(wù)透明，因?yàn)閷?duì)業(yè)務(wù)來說其實(shí)根本無需關(guān)心到底是分布式還是非分布式，僅需要按照正常業(yè)務(wù)開啟一個(gè)事務(wù)使用即可。第四個(gè)是完備的異常容錯(cuò)。分布式事務(wù)是否健壯也需要考慮容錯(cuò)性的能力。第五個(gè)是全局的鎖檢測。對(duì)于分布式環(huán)境下鎖檢測也是不可或缺的。TDSQL提供全局視角的分布式死鎖檢測，可清晰查看多個(gè)分布式事務(wù)之間的鎖等待關(guān)系。第六點(diǎn)是完全去中心化。無論是SQL引擎還是數(shù)據(jù)節(jié)點(diǎn)，都是支持高可用并且能夠線性擴(kuò)展。以上是TDSQL分布式事務(wù)的總結(jié)。如果說用戶要求保持跟MySQL的高度兼容性，那可能Noshard版TDSQL更適合。但是如果對(duì)于用戶來說，單節(jié)點(diǎn)已經(jīng)達(dá)到資源的瓶頸，沒有辦法