為幫助開發(fā)者更好地了解和學習分布式數(shù)據(jù)庫技術，2020年3月，騰訊云數(shù)據(jù)庫、云加社區(qū)聯(lián)合騰訊TEG數(shù)據(jù)庫工作組特推出為期3個月的國產數(shù)據(jù)庫專題線上技術沙龍《你想了解的國產數(shù)據(jù)庫秘密，都在這！》，邀請數(shù)十位鵝廠資深數(shù)據(jù)庫專家每周二和周四晚上在線深入解讀TDSQL、CynosDB/CDB、TBase三款鵝廠自研數(shù)據(jù)庫的核心架構、技術實現(xiàn)原理和最佳實踐等。本文將帶來直播回顧第四篇《億級流量場景下的平滑擴容：TDSQL的水平擴容方案實踐》。

點擊圖片看直播

以下是分享原文：

話不多說，我們正式進入今天的分享。今天分享的主題是“億級流量場景下的平滑擴容：TDSQL的水平擴容方案實踐”。

今天的分享我會主要包含這四部分：

第一部分首先介紹水平擴容的背景，主要介紹為什么要水平擴容，主要跟垂直擴容進行對比，以及講一下一般我們水平擴容會碰到的問題。

第二部分會簡單介紹TDSQL如何做水平擴容，讓大家有一個直觀的印象。

第三部分會詳細介紹TDSQL水平擴容背后的設計原理，主要會跟第一部分進行對應，看一下TDSQL如何解決一般水平擴容碰到的問題。

第四部分會介紹實踐中的案例。

1. 數(shù)據(jù)庫水平擴容的背景和挑戰(zhàn)

首先我們看水平擴容的背景。擴容的原因其實非常直觀，一般來說主要是隨著業(yè)務的訪問量，或者是需要的規(guī)模擴大，而現(xiàn)有的容量或者性能滿足不了業(yè)務的需求，主要表現(xiàn)在TPS、QPS不夠或者時延超過了業(yè)務的容忍范圍，或者是現(xiàn)有的容量不能滿足要求了，后者主要是指磁盤或者網絡帶寬。一般碰到這種問題，我們就要擴容。擴容來說，其實比較常見的就是兩種方式，一種是垂直擴容，一種是水平擴容。這兩種有不同的特點，優(yōu)缺點其實也非常明顯。

1.1 水平擴容 VS 垂直擴容

首先我們看一下垂直擴容。垂直擴容，主要是提高機器的配置，或者提高實例的配置。因為，我們知道，大家在云上購買一個數(shù)據(jù)庫或者購買一個實例，其實是按需分配的，就是說對用戶而言，可能當前的業(yè)務量不大，只需要兩個CPU或者是幾G的內存；而隨著業(yè)務的增長，他可能需要對這個實例進行擴容，那么他可能當前就需要20個CPU，或者是40G的內存。這個時候，在云上我們是可以通過對資源的控制來動態(tài)地調整，讓它滿足業(yè)務的需求——就是說可以在同一臺機器上動態(tài)增加CPU。這個擴容的極限就是——當整臺機器的CPU和內存都給它，如果發(fā)現(xiàn)還不夠的話，就需要準備更好的機器來進行擴容。這個在MySQL里面可以通過主備切換：通過先選好一臺備機，然后進行數(shù)據(jù)同步；等數(shù)據(jù)同步完成以后，進行主備切換，這樣就能利用到現(xiàn)在比較好的那臺機器。大家可以看到，這整個過程當中，對業(yè)務來說基本上沒有什么影響——進行主備切換，如果換IP的話，其實是通過前端的或者VIP的方式，對業(yè)務來說基本上沒有什么影響。那么它一個最大的不好的地方就是，它依賴于單機資源：你可以給它提供一個更好的機器，從而滿足一定量的要求。而隨著業(yè)務更加快速的發(fā)展，你會發(fā)現(xiàn)現(xiàn)在能提供的最好的機器，可能還是滿足不了，相當于擴不下去了。因此，垂直擴容最大的缺點就是，它依賴于單機的資源。

跟垂直擴容對比，另外一種方式我們叫水平擴容。水平擴容最大的優(yōu)點是解決了垂直擴容的問題——理論上水平擴容可以進行無限擴容，它可以通過增加機器的方式來動態(tài)適應業(yè)務的需求。

水平擴容和垂直擴容相比，它可以解決垂直擴容的問題，但是會引入一些其他的問題。因為水平擴容比垂直擴容更加復雜，下面我們分析下可能遇見的問題，以及后面我們會介紹TDSQL的解決方案：

• 首先，在垂直擴容里面，系統(tǒng)經過擴容以后，其實數(shù)據(jù)總體來說還是存在一個節(jié)點，一主多備架構中，備機上也存儲著所有數(shù)據(jù)。而水平擴容過程中數(shù)據(jù)會進行拆分，面臨的第一個問題是，數(shù)據(jù)如何進行拆分？因為如果拆分不好，當出現(xiàn)熱點數(shù)據(jù)時，可能結果就是，即使已經把數(shù)據(jù)拆分成很多份了，但是存儲熱點數(shù)據(jù)的單獨節(jié)點會成為性能瓶頸。

• 第二點，在整個水平擴容過程中，會涉及到數(shù)據(jù)的搬遷、路由的改變。那么整個過程中能否做到對業(yè)務沒有感知？或者是它對業(yè)務的侵入性大概有多少？

• 第三，在整個擴過程中，因為剛才有這么多步驟，如果其中一步失敗了，如何能夠進行回滾？同時，在整個擴容過程中，如何能保證切換過程中數(shù)據(jù)高一致性？

• 再者，在擴容以后，由于數(shù)據(jù)拆分到了各個節(jié)點，如何能保證擴容后的性能？因為理論上來說，我們是希望我隨著機器的增加，性能也能做到線性提升，這是理想的狀態(tài)。實際上在整個水平擴容的過程中，不同的架構或者不同的方式，對性能影響是比較大的。有時候會發(fā)現(xiàn)，可能擴容了很多，機器已經增加了，但是性能卻很難做到線性擴展。

同樣的，當數(shù)據(jù)已經拆分成多份，我們如何繼續(xù)保證數(shù)據(jù)庫分布式的特性？在單機架構下，數(shù)據(jù)存儲一份，類似MySQL支持本地做到原子性——可以保證在一個事物中數(shù)據(jù)要么全部成功，要么全部失敗。在分布式架構里，原子性則只能保證在單點里面數(shù)據(jù)是一致性的。因此，從全局來說，由于數(shù)據(jù)現(xiàn)在跨節(jié)點了，那么在跨節(jié)點過程中怎么保證全局的一致性，怎么保證在多個節(jié)點上數(shù)據(jù)要么全部寫成功，要么全部回滾？這個就會涉及到分布式事務。

所以大家可以看到，水平擴容的優(yōu)點很明顯，它解決了垂直擴容機器的限制。但是它更復雜，引入了更多的問題。接下來大家?guī)е@些問題，下面我會介紹TDSQL如何進行水平擴容，它又是如何解決剛才說的這些問題的。

2. TDSQL水平擴容實踐

首先我們看一下TDSQL的架構。TDSQL簡單來說包含幾部分：

• 第一部分是SQL引擎層：主要是作為接入端，屏蔽整個TDSQL后端的數(shù)據(jù)存儲細節(jié)。對業(yè)務來說，業(yè)務訪問的是SQL引擎層。

• 接下來是由多個SET組成的數(shù)據(jù)存儲層：分布式數(shù)據(jù)庫中，數(shù)據(jù)存儲在各個節(jié)點上，每個SET我們當做一個數(shù)據(jù)單元。它可以是一主兩備或者一主多備，這個根據(jù)業(yè)務需要來部署。有些業(yè)務場景對數(shù)據(jù)安全性要求很高，可以一主三備或者一主四備都可以。這個是數(shù)據(jù)存儲。

• 還有一個是Scheduler模塊，主要負責整個系統(tǒng)集群的監(jiān)控、控制。在系統(tǒng)進行擴容或者主備切換時，Scheduler模塊相當于是整個系統(tǒng)的大腦一樣的控制模塊。對業(yè)務來說其實只關注SQL引擎層，不需要關注Scheduler，不需要關注數(shù)據(jù)是怎么跨節(jié)點，怎么分成多少個節(jié)點等，這些對業(yè)務來說是無感知的。

整個擴容流程大家可以看一下：一開始數(shù)據(jù)都放在一個Set上，也就是在一個節(jié)點里面。那么擴容其實就是會把數(shù)據(jù)擴容到——這里面有256個Set，會擴容到256臺機器上。整個擴容大家可以看到有幾個要點：

• 一開始雖然數(shù)據(jù)是在一個節(jié)點上，在一臺機器上，但是其實數(shù)據(jù)已經進行了拆分，圖示的這個例子來說是已經拆分成了256份。

• 水平擴容，簡單來說就是把這些分片遷移到其他的Set上，也就是其他的節(jié)點機器上，這樣就可以增加機器來為提供系統(tǒng)性能。

總結起來就是說，數(shù)據(jù)一開始已經切分好了，擴容過程相當于把分片遷到新的節(jié)點，整個擴容過程中，節(jié)點數(shù)是增加的，可以從1擴到2擴到3，甚至擴到最后可以到256，但是分片數(shù)是不變的。一開始256個分片在一個節(jié)點上，擴成兩個節(jié)點的話，有可能是每128個分片在一個節(jié)點上；擴到最后，可以擴到256個節(jié)點上，數(shù)據(jù)在256臺機器，每臺機器負責其中的一個分片。因此整個擴容簡單來說就是搬遷分片。具體細節(jié)我們后面會講到。

在私有云或者是公有云上，對整個擴容TDSQL提供了一個統(tǒng)一的前臺頁面，用戶在使用的過程中非常方便。

我們看一下這個例子。現(xiàn)在這個案例中有兩個Set，也就是兩個節(jié)點，每一個節(jié)點負責一部分的路由，第一個節(jié)點負責0-31，另一個名字是3，負責的路由信息是32-63。現(xiàn)在是兩個節(jié)點，如果要進行擴容，在前臺頁面上我們會有一個“添加Set”的按紐，點一下“添加Set”，就會彈出一個對話框，里面默認會自動選擇之前的一個配置，用戶可以自己自定義，包括現(xiàn)在這個Set，需要多少資源以及內存、磁盤的分配等。

此外，因為擴容要進行路由切換，我們可以手動選擇一個時間，可以自動切換，也可以由業(yè)務判斷業(yè)務的實際情況，人工操作路由的切換。這些都可以根據(jù)業(yè)務的需要進行設置。

第一步創(chuàng)建好以后，剛才說大腦模塊會負責分配各種資源，以及初始化，并進行數(shù)據(jù)同步的整個邏輯。最后，大家會看到，本來第一個節(jié)點——原來是兩個節(jié)點，現(xiàn)在已經變成三個節(jié)點了。擴容之前，第一個節(jié)點負責是0-31，現(xiàn)在它只負責0-15，另外一部分路由由新的節(jié)點來負責。所以整個過程，大家可以看到，通過網頁上點一下就可以快速地從兩個節(jié)點添加到三個節(jié)點——我們還可以繼續(xù)添加Set，繼續(xù)根據(jù)業(yè)務的需要進行一鍵擴容。

3. TDSQL水平擴容背后的設計原理

剛才主要是介紹TDSQL的核心架構，以及水平擴容的特性和前臺操作，（幫助）大家建立直觀的印象。

第三章，我會詳細介紹一下TDSQL水平擴容背后的設計原理，主要是看一下第一章提到的水平擴容會遇到的一些問題，我們是如何來解決這些問題的。這些問題是不管在哪個系統(tǒng)做水平擴容，都需要解決的。

3.1 設計原理：分區(qū)鍵選擇如何兼顧兼容性與性能

首先我們剛才提到，水平擴容第一個問題是數(shù)據(jù)如何進行拆分。因為數(shù)據(jù)拆分是第一步，這個會影響到后續(xù)整個使用過程。對TDSQL來說，數(shù)據(jù)拆分的邏輯放到一個創(chuàng)建表的語法里面。需要業(yè)務去指定 shardkey “等于某個字段”——業(yè)務在設計表結構時需要選擇一個字段作為分區(qū)鍵，這樣的話TDSQL會根據(jù)這個分區(qū)鍵做數(shù)據(jù)的拆分，而訪問的話會根據(jù)分區(qū)鍵做數(shù)據(jù)的聚合。我們是希望業(yè)務在設計表結構的時候能夠參與進來，指定一個字段作為shardkey。這樣一來，兼容性與性能都能做到很好的平衡。

其實我們也可以做到用戶創(chuàng)建表的時候不指定shardkey，由我們底層這邊隨機選擇一個鍵做數(shù)據(jù)的拆分，但這個會影響后續(xù)的使用效率，比如不能特別好地發(fā)揮分布式數(shù)據(jù)庫的使用性能。我們認為，業(yè)務層如果在設計表結構時能有少量參與的話，可以帶來非常大的性能優(yōu)勢，讓兼容性和性能得到平衡。除此之外，如果由業(yè)務來選擇shardkey——分區(qū)鍵，在業(yè)務設計表結構的時候，我們可以看到多個表，可以選擇相關的那一列作為shardkey，這樣可以保證數(shù)據(jù)拆分時，相關的數(shù)據(jù)是放在同一個節(jié)點上的，這樣可以避免很多分布式情況下的跨節(jié)點的數(shù)據(jù)交互。

我們在創(chuàng)建表的時候，分區(qū)表是我們最常用的，它把數(shù)據(jù)拆分到各個節(jié)點上。此外，其實我們提供了另外兩種——總共會提供三種類型的表，背后的主要思考是為了性能，就是說通過將global表這類數(shù)據(jù)是全量在各個節(jié)點上的表——一開始大家會看到，數(shù)據(jù)全量在各個節(jié)點上，就相當于是沒有分布式的特性，沒有水平拆分的特性，但其實這種表，我們一般會用在數(shù)據(jù)量比較小、改動比較少的一些配置表中，通過數(shù)據(jù)的冗余來保證后續(xù)訪問，特別是在操作的時候能夠盡量避免跨節(jié)點的數(shù)據(jù)交互。其他方面，shardkey來說，我們會根據(jù)user做一個Hash，這個好處是我們的數(shù)據(jù)會比較均衡地分布在各個節(jié)點上，來保證數(shù)據(jù)不會有熱點。

3.2設計原理：擴容中的高可用和高可靠性

剛才也提到，因為整個擴容過程的流程會比較復雜，那么整個擴容過程能否保證高可用或者高可靠性，以及對業(yè)務的感知是怎么樣的，TDSQL是怎么做的呢？

• 數(shù)據(jù)同步

  第一步是數(shù)據(jù)同步階段。假設我們現(xiàn)在有兩個Set，然后我們發(fā)現(xiàn)其中一個SET現(xiàn)在磁盤容量已經比較危險了，比如可能達到80%以上了，這個時候要對它進行擴容，我們首先會新建一個實例，通過拷貝鏡像，新建實例，新建同步關系。建立同步的過程對業(yè)務無感知，而這個過程是實時的同步。

• 數(shù)據(jù)校驗

  第二階段，則是持續(xù)地追平數(shù)據(jù)，同時持續(xù)地進行數(shù)據(jù)校驗。這個過程可能會持續(xù)一段時間，對于兩個同步之間的延時差無限接近時——比如我們定一個5秒的閾值，當我們發(fā)現(xiàn)已經追到5秒之內時，這個時候我們會進入第三個階段——路由更新階段。

• 路由更新

  路由更新階段當中，首先我們會凍結寫請求，這個時候如果業(yè)務有寫過來的話，我們會拒掉，讓業(yè)務過兩秒鐘再重試，這個時候對業(yè)務其實是有秒級的影響。但是這個時間會非常短，凍結寫請求之后，第三個實例同步的時候很快就會發(fā)現(xiàn)數(shù)據(jù)全部追上來，并且校驗也沒問題，這個時候我們會修改路由，同時進行相關原子操作，在底層做到存儲層分區(qū)屏蔽，這樣就能保證SQL接入層在假如路由來不及更新的時數(shù)據(jù)也不會寫錯。因為底層做了改變，分區(qū)已經屏蔽了。這樣就可以保證數(shù)據(jù)的一致性。路由一旦更新好以后，第三個SET就可以接收用戶的請求，這個時候大家可以發(fā)現(xiàn)，第一個SET和第三個SET因為建立了同步，所以它們兩個是擁有全量數(shù)據(jù)的。

• 刪除冗余數(shù)據(jù)

  最后一步則需要把這些冗余數(shù)據(jù)刪掉。刪冗余數(shù)據(jù)用的是延遲刪除，保證刪除過程中可以慢慢刪，也不會造成比較大的IO波動，影響現(xiàn)網的業(yè)務。整個刪除過程中，我們做了分區(qū)屏蔽，同時會在SQL引擎層會做SQL的改寫，來保證當我們在底層雖然有冗余數(shù)據(jù)，但用戶來查的時候即使是一個全掃描，我們也能保證不會多一些數(shù)據(jù)。

可以看到整個擴容流程，數(shù)據(jù)同步，還有校驗和刪除冗余這幾個階段，時間耗費相對來說會比較長，因為要建同步的話，如果數(shù)據(jù)量比較大，整個拷貝鏡像或者是追binlog這段時間相對比較長。但是這幾個階段對業(yè)務其實沒有任何影響，業(yè)務根本就沒感知到現(xiàn)在新加了一個同步關系。那么假如在建立同步關系時發(fā)現(xiàn)有問題，或者新建備機時出問題了，也完全可以再換一個備機，或者是經過重試，這個對業(yè)務沒有影響。路由更新階段，理論上對業(yè)務寫請求難以避免會造成秒級的影響，但我們會將這個影響時間窗口期控制在非常短，因為本身凍結寫請求是需要保證同步已經在5秒之內這樣一個比較小的閾值，同步到這個階段以后，我們才能發(fā)起路由更新操作。同時，我們對存儲層做了分區(qū)屏蔽來保證多個模塊之間，如果有更新不同時也不會有數(shù)據(jù)錯亂的問題。這是一個我們如何保證擴容中的高可用跟高可靠性的，整個擴容對業(yè)務影響非常小的原理過程。

3.3設計原理：分布式事務

剛才講的是擴容階段大概的流程，以及TDSQL是如何解決問題的。接下來我們再看擴容完成以后，如何解決剛才說的水平擴容以后帶來的問題。首先是分布式事務。

• 原子性、去中心化、性能線性增長

  擴容以后，數(shù)據(jù)是跨節(jié)點了，系統(tǒng)本來只有一個節(jié)點，現(xiàn)在跨節(jié)點的話，如何保證數(shù)據(jù)的原子性，這個我們基于兩階段提交，然后實現(xiàn)了分布式事務。整個處理邏輯對業(yè)務來說是完全屏蔽了背后的復雜性，對業(yè)務來說使用分布式數(shù)據(jù)庫就跟使用單機MySQL一樣。如果業(yè)務這條SQL只訪問一個節(jié)點，那用普通的事務就可以；如果發(fā)現(xiàn)用戶的一條SQL或者一個事務操作了多個節(jié)點，我們會用兩階段提交。到最后會通過記日志來保證整個分布式事務的原子性。同時我們對整個分布式事務在實現(xiàn)過程中做到完全去中心化，可以通過多個SQL來做TM，性能也可實現(xiàn)線性增長。除此之外，我們也做了大量的各種各樣的異常驗證機制，有非常健壯的異常處理和全局的試錯機制，并且我們也通過了TPCC的標準驗證。

3.4 設計原理：如何實現(xiàn)擴容中性能線性增長

對于水平擴容來說，數(shù)據(jù)拆分到多個節(jié)點后主要帶來兩個問題：一個是剛才說事務原子性的問題，這個通過分布式事務來解決；還有一個就是性能。

垂直擴容中一般是通過更換更好的CPU或者類似的方法，來實現(xiàn)性能線性增加。水平擴容而言，因為數(shù)據(jù)拆分到多個節(jié)點上去，如何才能很好地利用起拆分下去的各個節(jié)點，進行并行計算，，真正把水平分布式數(shù)據(jù)庫的優(yōu)勢發(fā)揮出來，需要大量的操作、大量的優(yōu)化措施。TDSQL做了這樣一些優(yōu)化措施。

一是相關數(shù)據(jù)存在同一個節(jié)點上。建表結構的時候，我們希望業(yè)務能參與進來一部分，在設計表結構的時候指定相關的一些鍵作為shardkey，這樣我們就能保證后端的相關數(shù)據(jù)是在一個節(jié)點上的。如果對這些數(shù)據(jù)進行聯(lián)合查詢就不需要跨節(jié)點。

同樣，我們通過并行計算、流式聚合來實現(xiàn)性能提升——我們把SQL拆分分發(fā)到各個后臺的節(jié)點，然后通過每個節(jié)點并行計算，計算好以后再通過SQL引擎來做二次聚合，然后返回給用戶。而為了減少從后端把數(shù)據(jù)拉到SQL，減少數(shù)據(jù)的一個拉取的話，我們會做一些下推的查詢——把更多的條件下推到DB上。此外我們也做了數(shù)據(jù)冗余，通過數(shù)據(jù)冗余保證盡量減少跨節(jié)點的數(shù)據(jù)交互。

我們簡單看一個聚合——TDSQL是如何做到水平擴容以后，對業(yè)務基本無感知，使用方式跟使用單機MySQL一樣的。對業(yè)務來說，假設有7條數(shù)據(jù)，業(yè)務不用管這個表具體數(shù)據(jù)是存在一個節(jié)點還是多個節(jié)點，只需要插7條數(shù)據(jù)。系統(tǒng)會根據(jù)傳過來的SQL進行語法解析，并自動把這條數(shù)據(jù)進行改寫。7條數(shù)據(jù)，系統(tǒng)會根據(jù)分區(qū)鍵計算，發(fā)現(xiàn)這4個要發(fā)到第一個節(jié)點，另外3個發(fā)到第二個節(jié)點，然后進行改寫，改寫好之后插入這些數(shù)據(jù)。對用戶來說，就是執(zhí)行了這么一條，但是跨節(jié)點了，我們這邊會用到兩階段提交，從而變成多條SQL，進而保證一旦有問題兩邊會同時回滾。

數(shù)據(jù)插錄完以后，用戶如果要做一些查詢——事實上用戶不知道數(shù)據(jù)是拆分的，對他來說就是一個完整的表，他用類似聚合函數(shù)等進行查詢。同樣，這條SQL也會進行改寫，系統(tǒng)會把這條SQL發(fā)到兩個節(jié)點上，同時加一些平均函數(shù)，進行相應的轉換。到了各個節(jié)點，系統(tǒng)會先做數(shù)據(jù)聚合，到這邊再一次做聚合。增加這個步驟的好處是，這邊過來的話，我們可以通過做一個聚合，相當于在這里不需要緩存太多的數(shù)據(jù)，并且做到一個流式計算，避免出現(xiàn)一次性消耗太多內存的情況。

對于比較復雜的一些SQL，比如多表或者是更多的子查詢，大家有興趣的話可以關注我們后面的分享——SQL引擎架構和引擎查詢實戰(zhàn)。

以上第三章我們比較詳細地介紹了TDSQL整個水平擴容的一些原理，比如數(shù)據(jù)如何進行拆分，水平擴容實踐，以及如何解決擴容過程中的問題，同樣也介紹水平擴容以后帶來的一些問題，TDSQL是如何解決的。

4. 水平擴容實踐案例

第四章，我們簡單來介紹一些實踐和案例。

4.1 實踐：如何選擇分區(qū)鍵

剛才我們說，我們希望在創(chuàng)建表的時候業(yè)務參與進行表結構設計的時候，能考慮一下分區(qū)鍵的選擇。如何選擇分區(qū)鍵呢？這里根據(jù)幾種類型來簡單介紹一下。

如果是面向用戶的互聯(lián)網應用，我們可以用用戶對應的字段，比如用戶ID，來做分區(qū)鍵。這樣保證在擁有大量用戶時，可以根據(jù)用戶ID將數(shù)據(jù)拆分到各個后端節(jié)點。

游戲類應用，業(yè)務的邏輯主體是玩家，我們可以通過玩家對應的字段；電商應用的話，可以根據(jù)買家或者賣家的一些字段來作為分區(qū)鍵。物聯(lián)網的則可以通過比如設備的ID作為分區(qū)鍵。選擇分區(qū)鍵總體來說就是要做到對于數(shù)據(jù)能比較好地做進行拆分，避免最后出現(xiàn)漏點。也就是說，通過這個分區(qū)鍵選擇這個字段，可以讓數(shù)據(jù)比較均衡地分散到各個節(jié)點。訪問方面，當有比較多SQL請求的時候，其實是帶有分區(qū)鍵條件的。因為只有在這種情況下，才能更好地發(fā)揮分布式的優(yōu)勢——如果是條件里面帶分區(qū)鍵，那這條SQL可以直接錄入到某一個節(jié)點上；如果沒有帶分區(qū)鍵，就意味著需要把這條SQL發(fā)到后端所有節(jié)點上。

這個大家可以看到，如果水平擴容到更多——從一個節(jié)點擴到256個節(jié)點，那某一條SQL寫不好的話，可能需要做256個節(jié)點全部的數(shù)據(jù)的聚合，這時性能就不會很好。

總結來說，我們希望業(yè)務在創(chuàng)建表，在設計表結構的時候盡量參與進來。因為不管是聚合函數(shù)或者是各種事務的操作，其實對業(yè)務基本上屬于無感知，而業(yè)務這時參與則意味著能夠換來很大的性能提升。

4.2 實踐：什么時候擴容？

我們什么時候擴容？在TDSQL里面，我們會有大量的監(jiān)控數(shù)據(jù)，對于各個模塊我們在本地會監(jiān)控整個系統(tǒng)的運行狀態(tài)，機器上也會有各種日志上報信息。基于這些信息，我們可以決定什么時候進行擴容。

簡單來說，比如磁盤——如果發(fā)現(xiàn)數(shù)據(jù)磁盤使用率太高，這個時候可以進行擴容；或者SQL請求，或者CPU使用率接近100%了——目前基本假如達到80%使用率就要進行擴容。還有一種情況是，可能現(xiàn)在這個時候其實請求量比較少，資源使用比較充足，但如果業(yè)務提前告訴你，某個時候將進行一個活動，這個活動到時候請求量會增長好幾倍，這個時候我們也可以提前完成擴容。

下面再看幾個云上的集群案例。這個大家看到，這個集群有4個SET，每個SET負責一部分的shardkey，這個路由信息是0-127，意思是它最后能擴到128個節(jié)點，所以能擴128倍。這個“128”可以由初始化的業(yè)務預估先定下來。因為如果池子太大的話，的確最后可以擴到幾千臺，但是數(shù)據(jù)將比較散了。事實上今天每臺云上的或者實際的機器性能已經非常好，不需要幾千臺的規(guī)格。

這是另外一個集群——它的節(jié)點數(shù)會多一點，有8個節(jié)點，每個節(jié)點也負責一部分的路由信息。這個數(shù)字只有64，所以這個最后可以擴到64個節(jié)點。這個是云上的相關例子。

今天我的分享主要是這些內容，大家如果有什么問題歡迎評論留言。

Q&A：

Q：沒擴容之前的SET里面的表都是分區(qū)表，問一下是不是分區(qū)表？

A：是的，在沒擴容之前，相當于在這個，簡單說我們現(xiàn)在就一個節(jié)點，那么我們告訴他256，這個值我們在進行初始化的時候就定下來的。而且這個值集群初始化以后就不會再變了。假設我們這個集群定了一個值是256——因為他可能認為這個數(shù)據(jù)量后面會非常非常大，可以定256。這個時候，數(shù)據(jù)都在一個節(jié)點上。這個時候用戶，按照我們剛才的語法創(chuàng)建了一個表，這個表在底層其實是分成256份的。所以他即使沒有進行擴容，它的數(shù)據(jù)是256份。再創(chuàng)建另外一個表，也是256份。用戶可能創(chuàng)建兩個表，但是每個表的底層我們有256個分區(qū)的，擴容就相當于分區(qū)把它遷到其他的地方去。

Q：各個節(jié)點的備份文件做恢復時如何保證彼此之間的一致性？

A：各個節(jié)點之間沒有相互關系，各個節(jié)點自己負責一部分的路由號段，只存儲部分數(shù)據(jù)，水平擴容只負責一部分數(shù)據(jù)，它們之間的備份其實是沒有相互的關系，所以這個備份其實是之間不相關的。每個節(jié)點我們可能有一主兩備，這個其實是我們有強同步機制，在復制的時候來保證數(shù)據(jù)強一致性。大家可以參考之前的分享里面會比較詳細介紹TDSQL在單個節(jié)點里面TDSQL一主多備架構是如何保證數(shù)據(jù)的強一致性的。

Q：兩階段在協(xié)調的時候能避免單點故障嗎？

A：首先在兩階段提交的時候，我們是用SQL引擎做事務的協(xié)調，這個是單個的事務。如果其他的連接發(fā)過來，可以拿其他的SQL引擎做事務協(xié)調期。而且每個SQL引擎是做到無狀態(tài)的，可以進行水平擴展。所以這個其實是不會有太多的故障，我們可以根據(jù)性能隨機擴展的，可以做到性能的線性增長，沒有中心化。日志這些都是被打散的，記日志也會記到TDSQL后端的數(shù)據(jù)節(jié)點里面，一主多備，內部保證強一致性，不會有單點故障。

Q：剛看了下TDSQL的分片設計，實際上固定255分片，所謂擴容，實際上是搬移分片，而不是增加分片。這個感覺是不是不夠靈活，特別大的表才有必要分255吧，而且分255對網絡的開銷也挺大的，尤其是limit m,n。要是分片數(shù)靈活可變就更好了，因為總是有可能找不到適合分255的字段的。
A：分區(qū)數(shù)量在創(chuàng)建集群的時候是可以指定的，如果預期未來的數(shù)據(jù)量增長很大，分區(qū)數(shù)可以設置大一些。另外limit m,n 的網絡開銷取決于參與查詢的set數(shù)量，而不取決于分區(qū)的數(shù)量，處于同一個set中的某表的所有分區(qū)，一個查詢就能夠獲取所有結果，而不需要對每個分區(qū)進行一次查詢。

TDSQL是騰訊TEG數(shù)據(jù)庫工作組三大產品系之一，是一款騰訊自研的金融級分布式數(shù)據(jù)庫產品，在國產數(shù)據(jù)庫領域屢次率先突破，包括助力微眾銀行搭建首個全行級互聯(lián)網銀行核心系統(tǒng)，以及助力張家港農商行實現(xiàn)傳統(tǒng)核心系統(tǒng)數(shù)據(jù)庫首次國產化等。目前，TDSQL已廣泛應用于金融、政務、物聯(lián)網、智慧零售等行業(yè)，擁有大量分布式數(shù)據(jù)庫最佳實踐。

推薦閱讀：

丁奇：深入解讀騰訊云國產數(shù)據(jù)庫技術演進歷程

騰訊分布式數(shù)據(jù)庫TDSQL金融級能力的架構原理解讀

騰訊數(shù)據(jù)庫RTO<30s,RPO=0高可用方案首次全景揭秘

總結

以上是生活随笔為你收集整理的亿级流量场景下的平滑扩容：TDSQL的水平扩容方案实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。