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

2、對如：電商的大型促銷，春節搶紅包等突增流量的場景，這些其實都是對數據庫應對海量用戶流量的考驗。目前TDSQL已經服務超過500+的金融政企，行業覆蓋銀行、保險、證券、政務、互聯網金融等各個領域。我們再看一下TDSQL的前世今生。TDSQL最早可以追溯到2002年，那個時候其實還不叫TDSQL，它是騰訊計費平臺部的一個數據庫服務，當時使用了開源的MySQL。2002年-2007年隨著公司業務的發展，騰訊所面臨的用戶量的壓力也越來越大。這個時候我們提出了724小時不宕機的高可用設計方案，來保證數據庫能提供724小時不間斷連續高可用服務。那個時候，騰訊的增值業務日漸成規模，業務對數據也越來越敏感，對

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

4、了微眾銀行對數據可用性和一致性的要求。借此機會，TDSQL成功在微眾銀行投產，成為微眾銀行唯一的數據庫，覆蓋了銀行的核心業務。所以說2014年，TDSQL完成了商業化，也實現了私有化部署。2014年以后，TDSQL推廣到了很多銀行、金融機構，這過程中是借鑒了2014年TDSQL在微眾銀行成功實施的寶貴的經驗。因為在2014年微眾銀行的部署中，我們也踩了很多坑，也認識到在私有化部署環境的各種各樣的挑戰，并一一攻克了這些挑戰。當2014年在私有化部署完成之后，再到2015年TDSQL上公有云，我們繼續通過公有云服務打磨自己的產品。所以從2012年作為一個內部產品到2014年的私有化部署，再到201

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

6、系統上分布式數據庫的銀行，分布式數據庫不再是只局限于銀行的互聯網核心、互聯網銀行等外圍系統的嘗試，而是真真正正切入到銀行系統的心臟傳統核心，這也是國產數據庫領域一個具有里程碑意義的事件。所以在未來，我們也將繼續“走出去”深入到更復雜、更新核心的業務系統，打磨我們的產品。這是TDSQL的發展歷程。TDSQL核心特性：極具挑戰的“四高”服務與安全可運維我們再看TDSQL的核心特性。首先作為適應于金融場景的數據庫，數據強一致性是立命之本，因為數據不能丟、不能錯。在金融場景，你沒有辦法去估量假如錯一條數據，到底這條數據是1分錢還是1個億，所以數據強一致是我們最根本的一個特性。不允許丟，不允許錯，這是對

7、數據庫起碼的要求。第二是金融級高可用。TDSQL確保99.999%以上的可用性，并支持跨IDC、多機房、同城多活的部署方式。我們最先切入金融場景是因為金融場景的挑戰是最大的。中國金融行業受監管要求最為苛刻，同時也對數據和業務的可用性、可靠性、一致性更是有極高的要求。我們要求99.999%的可用性，也就是說這個數據庫全年故障的時間不能超過5分鐘。第三是高性能、低成本。互聯網時代的企業，都是海量業務、海量機器，性能稍微提高一個10%，可能就節約成百上千臺機器的成本，這個經濟效益還是比較大的。所以高性能、低成本也是TDSQL的一個關鍵特性。第四點是線性水平擴展。因為無論是互聯網還是其他企業，隨著數字

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

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

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

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

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

13、得先去看到是哪一個實例、涉及到哪一臺機器、這個機器有什么問題、檢測機器的健康狀態這些都是機械性的工作，有了扁鵲智能管理平臺，當出現故障的時候就可以自動分析故障的原因，舉個例子，可以找出是因為什么導致SQL變慢了，或者又是因為什么原因發生了主備切換，突然IO異常了或者其他什么原因導致機器故障。此外，扁鵲智能DBA平臺還有一個智能診斷系統，可以定期由DBA發起對實例進行的診斷。比如有些數據庫實例，CPU常年跑得很高，其實是一些比較差的SQL導致的。這個時候扁鵲智能DBA系統，可以很方便地到用戶實例上做巡檢，得到一個健康狀況圖，并對它進行打分，發現這個實例比如他的CPU超用了，需要擴容，但是沒有擴容

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

15、數據庫之間的遷移服務我們TDSQL怎么能夠幫助異地數據庫遷進來，或者從TDSQL再遷出。此外，還包括數據校驗、數據訂閱、SQL防火墻、注入檢測等安全方面的模塊，以及一個輔助模塊幫助我們的DBA也好，用戶也好，完成一些個性化的豐富的需求。以上是TDSQL系統總覽。TDSQL架構模塊及其特性我們再看一下核心架構。核心架構其實是上一個圖的縮覽，我們把核心的模塊挑選出來。首先用戶的請求通過負載均衡發往SQL引擎。然后，SQL引擎作為計算接入層，根據這個SQL的要求從后端的存儲節點去取數據。當然，無論是SQL引擎還是后端的數據庫實例都存在一個元數據來管理調度。舉個例子，計算引擎需要拿到一個路由，路由告訴

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

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

18、，這個按紐可能是對實例進行擴容，這個按紐會把這個https的請求轉移到OSS模塊，這個OSS模塊有點像web服務器，它能接收web請求，但是它可以把這個轉發到ZK。所以，OSS模塊就是一個前端到后臺的橋梁，有了OSS模塊，整個后臺的工作模塊都可以跟前臺、跟web界面綁定在一起。好，捕捉到這個請求之后，在ZK上創建一個任務節點，這個任務節點被調度模塊捕獲，捕獲之后就處理任務。處理完任務，再把它的處理結果返回到ZK上。ZK上的任務被OSS捕獲，最后也是https的請求，去查詢這個任務，最后得到一個結果，返回給前端。這是一個純異步的過程，但是有了這套管理模塊，讓我們可以輕松的通過web界面去管理整個

19、TDSQL的后臺。當然，這整個過程都有一個監控采集模塊去采集，對整個流程的審計及狀態進行獲取。DB模塊：數據庫無損升級DB模塊，即數據節點，數據存取服務屬于IO密集型的服務，因此，數據節點也是我們的存儲節點，它對IO的要求比較高，一般建議配置SSD硬盤，最好是PCI-E的SSD。因為對數據庫服務來說，CPU再高，如果IO跟不上，仍然是小馬拉大車。比如只有1千的IOPS，CPU根本就跑不起來，用不起來。所以這里一般建議至少IOPS要達到1萬以上。我們再看一下SET的概念。SET就是數據庫實例，一個SET包含數據庫的比如我們默認要求的是一主兩備，一個Master節點和兩個Slave節點。當然在DB

20、節點上有一個Agent的模塊。MySQL在執行中，我們要監控它的行為，以及進行操作。如果把這些東西做到MySQL里面為什么不可以呢？這其實存在一個問題，如果對數據節點進行升級，可能就要涉及到重啟，一旦重啟就影響用戶的業務，影響服務。這個時候我們就考慮，在它上面加一個模塊Agent，它來完成對所有集群對MySQL的操作，并且上報MySQL的狀態。有了它之后，對TDSQL數據節點的大部分升級，都會轉變為對Agent的升級，而升級Agent，對業務沒有任何影響，這就實現了無損升級。相比于Agent我們對數據節點MySQL不會頻繁升級，一般情況下一年、半年都不會動它。這是我們DB模塊，也是存儲節點。S

21、QL引擎模塊：分布式復雜SQL處理接下來再看另外一個比較重要的模塊：SQL引擎模塊。SQL引擎處于計算層的位置，本身屬于CPU密集型，所以我們在選機型上盡量要求CPU高一些。其次是內存，作為計算接入層，它要管理鏈接，如果是大量的短鏈接或者長鏈接，非常占內存，所以它對CPU和內存的要求比較高。此外，它本身不存儲數據，也沒有主備之分，所以對硬盤沒有太大要求。我們看一下SQL引擎的特性。SQL引擎首先還是從ZK上拉取到元數據，作為SQL引擎，包括權限校驗、讀寫分離，以及統計信息、協議模擬等相關的操作。可能有些人會問，其實這個SQL引擎豈不是一種中間件？其實并不是這樣，SQL引擎如果是一個中間件，它都

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

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

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

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

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

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

28、就達到了接近于異步復制的性能，這就是TDSQL在強同步的改造的核心。所以我們這里強調不單單是一個實現強同步的過程，更是一個接近異步性能的強同步。再看一下改造之后的性能對比：異步TPS大概是6萬左右，平均時耗小于等于10毫秒。再看半同步，明顯有三分之二的性能損耗，并且這個時耗波動還是比較大的，比如說IDC網絡抖動一下。強同步一主兩備模式下，首先性能已經接近于異步的性能，此外時耗并沒有額外增加。TPS跟場景相關，數據僅提供橫向對比參考因為一主兩備，除非兩個機房網絡同時抖動，否則的話強同步的時耗不會有明顯波動。所以我們看到基于TDSQL的強同步實現了數據的多副本又保證了性能。有了這個多副本保障，又怎

29、么如何實現故障自動切換，數據不丟不錯呢？這其實還是需要一套切換選舉的流程。這就引出了TDSQL的容災切換功能。自動容災切換：數據強一致、0丟失0出錯自動容災切換在有了強同步特性的基礎，就變得非常容易實現了。我們先看一下這個結構圖：SQL引擎將請求發給主節點，主節點被兩個備機所同步，每個節點上都有對應的Agent上報當前節點的狀態。這時，主節點發生了故障被Agent覺察，上報到zk被Scheduler捕獲，然后Scheduler首先會把這個主節點進行降級，把它變成Slave。也就是說此時其實整個集群里面全是Slave，沒有主節點。這個時候另外兩個存活的備機上報自己最新的binlog點，因為有了強

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

31、性保障聊完了容災切換，我們再聊一聊故障節點的后續處理事宜。故障處理可能有幾種情況：一種是故障以后，它還能活過來。比如說像機房可能突然掉電了，掉完電之后它馬上又恢復。或者機器因為硬件原因不小心發生了重啟，重啟完之后節點是可以被拉起，被拉起之后，我們希望它能夠迅速的再加入到集群中，這時數據其實是沒有丟沒有錯的，我們不希望把節點故障之后又重新建一份數據，把之前的數據全抹掉。而是從它最后一次同步的數據為斷點，繼續續傳后面的數據。帶著上述問題，我們看一下節點的故障后恢復過程。首先我們考慮一種場景，比如說A節點作為主節點，B、C是從，正常去同步A節點的數據，A+1、A+2，接下來該同步A+3。當A+3還沒

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

33、點換掉，即換一個新機器，比如：加一個D節點。我們希望它快速重建數據并且對當前線上業務盡可能無影響。如何讓它快速去重建呢？當然是基于物理拷貝，而且它是從備機上去拉數據，這樣它既不會對主節點產生影響，又能夠快速把數據重建好。分布式TDSQL的實踐第四部分，我們開始講分布式TDSQL的實踐。前三章我們在聊TDSQL的高可用、強一致。這些作為金融場景是一個必備的特性，還沒有涉及到分布式，當涉及到分布式時就開啟了TDSQL的另外一種形態。接下來我們就聊一聊分布式TDSQL跟單節點的TDSQL有什么不同，以及這種分布式架構下又是如何實現一系列的保障，同時如何做到對業務透明、對業務無感知。分表分表，當在單機

34、模式下，用戶看到的一張邏輯表，其實也是一張物理表，存儲在一個物理節點（物理機）上。在分布式形態下，用戶看到的邏輯表的實際物理存儲可能是被打散分布到不同的物理節點上。所以TDSQL分表的目標，希望做到對業務完全透明，比如業務只看到一個完整的邏輯表，他并不知道這些表其實已經被TDSQL均勻拆分到各個物理節點上。比如：之前可能數據都在一臺機器上，現在這些數據平均分布在了5臺機器上，但用戶卻絲毫沒有覺察，這是TDSQL要實現的一個目標在用戶看來是完全的一張邏輯表，實際上它是在后臺打散了的。這個表在后臺如何去打散，如何去分布呢？我們希望對用戶做到透明，做到屏蔽，讓他不關心數據分布的細節。怎么將這個數據分

35、布和打散呢？這就引出了一個概念：shardkey是TDSQL的分片關鍵字，也就是說TDSQL會根據shardkey字段將這個數據去分散。我們認為，shardkey是一個很自然的字段，自然地通過一個字段去將數據打散。舉個例子，騰訊內部我們喜歡用QQ號作為一個shardkey，通過QQ號自動把數據打散，或者微信號；而一些銀行類的客戶，更喜歡用一些客戶號、身份證號以及銀行卡號，作為shardkey。也就是說通過一個字段自然而然把這個數據分散開來。我們認為引入shardkey后并不會增加額外的工作，因為首先用戶是最了解自己的數據的，知道自己的數據按照什么字段均勻分布最佳，同時給用戶自主選擇分片關鍵字的

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

37、里，以“ID”作為分配關鍵字，這樣六條數據就均勻分散到了兩個分片上。當然，數據均勻分散之后，我們要求SQL在發往這邊的都需要帶上shardkey，也就是說發到這里之后可以根據對應的shardkey發往對應的分片。如果不帶這個shardkey的話，它不知道發給哪個分片，就發給了所有分片。所以強調通過這樣的改善，我們要求盡可能SQL要帶上shardkey。帶上shardkey的話，就實現了SQL的路由分發到對應的分片。講完數據分片，我們再看一下數據的拆分。水平拆分對于分布式來說，可能最初我們所有的數據都在一個節點上。當一個節點出現了性能瓶頸，需要將數據拆分，這時對我們TDSQL來說非常簡單，在界面

38、上的一個按紐：即一鍵擴容，它就可以將這個數據自動拆分。拆分的過程也比較容易理解，其實就是一個數據的拷貝和搬遷過程，因為數據本身是可以按照一半一半這樣的劃分的。比如最先是這么一份數據，我們需要拆成兩份，需要把它的下半部分數據拷到另外一個節點上。這個原理也比較簡單，就是一個數據的拷貝，這里強調的是在拷貝的過程中，其實業務是不受任何影響的。最終業務只會最終有一個秒級凍結。為什么叫秒級凍結？因為，最后一步，數據分布到兩個節點上涉及到一個路由信息變更，比如原來的路由信息要發到這個分片，現在改了之后需要按照劃分，上半部分要發給一個分片，下半部分發給另一個分片。我們在改路由的這個過程中，希望這個數據是沒有寫

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

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

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

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