一、業(yè)務(wù)增長MySQL帶來的業(yè)務(wù)痛點分析：

1. 性能瓶頸：

• 隨著公司的業(yè)務(wù)快速發(fā)展，數(shù)據(jù)庫中的數(shù)據(jù)量猛增，訪問性能也變慢了，單臺MySQL實例無法應(yīng)對和滿足大規(guī)模數(shù)據(jù)管理和請求訪問，導(dǎo)致數(shù)據(jù)庫性能下降，成為瓶頸。
• 關(guān)系型數(shù)據(jù)本身就比較容易形成系統(tǒng)瓶頸，無論是從單機存儲容量、連接數(shù)、處理能力都有限。
• 當單表的數(shù)據(jù)量達到1000W以后，由于查詢和操作的維度較廣，哪怕使用了MySQL從庫讀寫分離、優(yōu)化索引等操作時，性能還是無可避免嚴重下降。

2. 數(shù)據(jù)強一致性同步延遲：

• 當架構(gòu)增加Redis、RabbitMQ等消息隊列
• OLTP的大數(shù)據(jù)量統(tǒng)計數(shù)據(jù)類異構(gòu)表同步只能滿足業(yè)務(wù)的T+1
• 系統(tǒng)架構(gòu)中，異步設(shè)計方案中的中間件故障，導(dǎo)致數(shù)據(jù)重傳、數(shù)據(jù)丟失

二、數(shù)據(jù)庫應(yīng)用的類型：

所以，在日常的企業(yè)級應(yīng)用中，OLAP和OLTP針對不同的業(yè)務(wù)場景，有不同的解決方案。OLAP主要用于企業(yè)級決策和戰(zhàn)略分析，需要快速的數(shù)據(jù)查詢和分析技術(shù)。相反，OLTP主要用于企業(yè)日常操作，需要快速的數(shù)據(jù)更新和處理技術(shù)。

三、項目中的優(yōu)化手段之《分庫分表》：

1. 業(yè)務(wù)痛點：

• 由于數(shù)據(jù)量過大而導(dǎo)致數(shù)據(jù)庫性能降低的問題

2. 解決的問題：

• 優(yōu)化單一表數(shù)據(jù)量過大而產(chǎn)生的性能問題，使得單個表的數(shù)據(jù)量變小，提高檢索性能，一定程度上可以緩解查詢性能瓶頸
• 避免IO爭搶并減少鎖表的幾率
• 解決業(yè)務(wù)層面的耦合，業(yè)務(wù)清晰
• 能對不同業(yè)務(wù)的數(shù)據(jù)進行分級管理、維護、監(jiān)控、擴展等
• 高并發(fā)場景下，在一定程度的提升IO、數(shù)據(jù)庫連接數(shù)、降低單機硬件資源的瓶頸
• 有些系統(tǒng)中使用的“冷熱數(shù)據(jù)分離”，備份歷史庫
• 在高并發(fā)和海量數(shù)據(jù)的場景下，分庫分表能夠有效緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源的瓶頸

3. 帶來新的問題：

• 跨庫join（安全性等方面考慮，一般是禁止跨庫join的）
• 分布式事務(wù)
• 業(yè)務(wù)復(fù)雜度增加
• 投入的硬件成本也會更高
• 跨分片的復(fù)雜查詢，跨分片事務(wù)等
• 跨節(jié)點關(guān)聯(lián)查詢
• 跨節(jié)點多庫進行查詢時，limit分頁，order by排序問題，就變得比較復(fù)雜
• 主鍵避重，主鍵值ID無法保證全局唯一
• 公共表、參數(shù)表、數(shù)據(jù)字典表等都是數(shù)據(jù)量較小，變動少，每個數(shù)據(jù)庫都保存一份

四、TDSQL-C MySQL Serverless解決的痛點：

TDSQL-C MySQL Serverless實例提供了CPU、內(nèi)存的實時彈性能力，構(gòu)建云上資源架構(gòu)下的MySQL產(chǎn)品新形態(tài)。

1. 常規(guī)業(yè)務(wù)下的痛點：

2. Serverless數(shù)據(jù)庫特點：

舉個場景：如果自己想要出行就只能購買汽車、摩托車，現(xiàn)在可以直接通過滴滴等第三方平臺使用打車服務(wù)，只需輸入目的地即可，不需要再關(guān)注買車的坑、開車怕被撞和汽車保養(yǎng)的問題，核心訴求得到了更好的滿足。

Serverless數(shù)據(jù)庫可以看做，直接在云上直接購買虛擬機，部署業(yè)務(wù)，負責服務(wù)的擴縮容，從CI/CD到服務(wù)部署，擴縮容，全部自動完成，用戶只需要更專注于業(yè)務(wù)代碼即可。

Serverless數(shù)據(jù)庫的基本特點是無需運維、以API方式提供服務(wù)、按實際使用計費、無使用無費用等。

3. 在業(yè)務(wù)波動較大的場景下，普通實例和Serverless實例資源使用和規(guī)格變化情況如下圖所示：

由上圖可以看到，在業(yè)務(wù)波動較大的場景下：

總結(jié)：由于Serverless實例的規(guī)格會隨業(yè)務(wù)需求量隨時調(diào)整，總體浪費的資源很少，提升了資源利用率，降低了資源使用量。

4. TDSQL-C MySQL Serverless的優(yōu)勢：

5. 適用場景：

• 開發(fā)、測試環(huán)境等低頻數(shù)據(jù)庫使用場景
• 中小企業(yè)建站服務(wù)等SaaS應(yīng)用場景
• 個人開發(fā)者用戶
• 學(xué)校教學(xué)、學(xué)生實驗等教育場景
• 物聯(lián)網(wǎng)（IoT）、邊緣計算等不確定負載場景
• 全托管或希望完全免運維的用戶
• 業(yè)務(wù)有波動或不可預(yù)測的用戶
• 具有間歇性定時任務(wù)的業(yè)務(wù)場景

五、TDSQL-C Serverless數(shù)據(jù)庫的三大特性：

Serverless 是騰訊自研云原生數(shù)據(jù)庫 TDSQL-C MySQL 版的無服務(wù)器架構(gòu)版，自動擴縮容，僅按照實際使用量計費，不用不計費，輕松應(yīng)對業(yè)務(wù)數(shù)據(jù)量動態(tài)變化和持續(xù)增長。

1. 自動啟停，不使用無計費：

Serverless 服務(wù)支持自定義實例自動暫停時間，無連接時實例會自動暫停。當有任務(wù)連接接入時，實例會秒級無間斷自動喚醒。

2. 按使用量計費：

可調(diào)整 CCU 彈性擴縮容的范圍，Serverless 集群會在該范圍內(nèi)根據(jù)實際業(yè)務(wù)壓力自動增加或減少 CCU。

3. 自動擴縮容：

Serverless 集群會持續(xù)監(jiān)控用戶的 CPU、內(nèi)存等 workload 負載情況，根據(jù)一定的規(guī)則觸發(fā)自動擴縮容策略。

六、自動啟停，不使用無計費：

1. 需求描述：

2. 測試方案：

date +"%T.%N" && mysql -h gz-cynosdbmysql-grp-9eujfhd.sql.tencentcdb.com -P 27304 -u root -pDb123. -Nse "show databases" && date +"%T.%N"

3. 測試結(jié)果分析：

Linux的date命令可以用來顯示或設(shè)定系統(tǒng)的日期與時間，通過獲取命令開始前時間，再獲取命令開始后時間，可以得到這條命令一共花費的時間值。

命令參數(shù)：
%T 時間(含時分秒，小時以24小時制來表示)。
%N 在顯示時，插入新的一行。

先將TDSQL-C MySQL如上述兩種方法停掉，使用MySQL自帶的“show databases”命令查看所有的數(shù)據(jù)庫，因為默認的命令，也不涉及到什么慢查詢，只能算空負載運行。可以看到執(zhí)行的時間差，可以是秒級連接。

從TDSQL-C MySQL的實時監(jiān)控報表也可以看出，在14：15之前的時間段是暫停的狀態(tài)，在15：00左右，有連接訪問，馬上就秒級啟動服務(wù)器，充分的說明了當沒有數(shù)據(jù)庫請求時，監(jiān)控服務(wù)會觸發(fā)計算資源的回收。當用戶再次訪問時，接入層則會喚醒集群，再次提供訪問。

4. 原理說明：

TDSQL-C Serverless冷啟動秒級內(nèi)就能完成，怎么做到能貼近云函數(shù)的啟動時間呢？

當有連接訪問時，系統(tǒng)會秒級自動啟動處于暫停狀態(tài)的數(shù)據(jù)庫，用戶不需設(shè)置重連機制。

• TDSQL-C MySQL 版的接入層增加了一個恢復(fù)感知器（簡稱 perceptron）的模塊來實現(xiàn)請求轉(zhuǎn)發(fā)，perceptron 在和客戶端握手之后，不會使用戶端到集群的連接斷連?；謴?fù)集群后，與 TDSQL-C MySQL 版握手，后續(xù)轉(zhuǎn)發(fā)四層報文。
• 整體流程設(shè)計采用了兩個挑戰(zhàn)隨機數(shù)進行鑒權(quán)，以實現(xiàn)中繼模塊 perceptron 不存儲用戶名密碼的情況下也可以完成用戶名密碼驗證，保證了用戶密碼的安全性，也不會引入存儲密碼不一致的問題。

• 當集群處于暫停狀態(tài)時，僅保留 perceptron 的路由
• 當集群恢復(fù)后時，系統(tǒng)同時保留 perceptron 的路由和 TDSQL-C 的路由，并設(shè)置 perceptron 的路由權(quán)重為 0，以實現(xiàn)新增連接直連到 TDSQL-C，同時存量與perceptron 已經(jīng)建連的連接依然能夠通訊。

七、按使用量計費：

1. TDSQL-C MySQL 版 Serverless 服務(wù)的計費說明：

定義了一個算力單元CCU（TDSQL-C Compute Unit）=max {CPU, MEM/2, 最小規(guī)格}。

• MEM/2的含義是，由于定義的規(guī)格CPU/內(nèi)存比都是1/2，內(nèi)存除以2相當于把內(nèi)存換算成CPU。
• 整體還是以CPU決定整個算力。
• 通過計算每個小時CCU平均值給用戶計費。

2. 創(chuàng)建一張訂單表：

創(chuàng)建一張訂單表，用于方便寫SQL語句進行壓測，如下我們會進行一下insert寫的場景壓測，分析一下，TDSQL-C MySQL怎么樣實現(xiàn)使用量計費。

CREATE TABLE `orders` (
  `order_id` bigint(20) NOT NULL COMMENT '訂單編號',
  `customer_id` bigint(10) NOT NULL COMMENT '下單用戶編號',
  `product_id` bigint(15) NOT NULL COMMENT '產(chǎn)品編號',
  `product_name` varchar(30) NOT NULL COMMENT '產(chǎn)品名稱',
  `product_price` decimal(10,2) NOT NULL COMMENT '產(chǎn)品價格',
  `quantity` int(11) NOT NULL COMMENT '產(chǎn)品數(shù)量',
  `total_price` decimal(10,2) NOT NULL COMMENT '總價格',
  `order_time` datetime NOT NULL COMMENT '下單時間',
  `delivery_time` datetime NOT NULL COMMENT '發(fā)貨時間',
  `status` int(1) NOT NULL DEFAULT '1' COMMENT '訂單狀態(tài) 1：已完成 0：未完成',
  `address` varchar(100) NOT NULL COMMENT '家庭住址',
  `phone` bigint(11) NOT NULL COMMENT '聯(lián)系電話',
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='訂單信息表';

創(chuàng)建表執(zhí)行SQL成功。

3. 使用騰訊云的“云壓測”進行測試：

云壓測（Performance Testing Service, PTS）是一款分布式性能測試服務(wù)，可模擬海量用戶的真實業(yè)務(wù)場景，全方位驗證系統(tǒng)可用性和穩(wěn)定性。支持按需發(fā)起壓測任務(wù)，提供百萬并發(fā)多地域流量發(fā)起能力。提供流量錄制、場景編排、流量定制、高級腳本定制等功能，可快速根據(jù)業(yè)務(wù)模型定義壓測場景，真實還原應(yīng)用大規(guī)模業(yè)務(wù)訪問場景，幫助用戶提前識別應(yīng)用性能問題。

創(chuàng)建一個壓測的案例場景，為了更好的說明按使用量來計費，我們選擇了遞增壓測的方案，模擬一下根據(jù)不同的業(yè)務(wù)量，產(chǎn)生不同的負載，Serverless 集群會在該范圍內(nèi)根據(jù)實際業(yè)務(wù)壓力自動增加或減少 CCU，根據(jù)不同的算力CCU產(chǎn)生不同的費用。

壓測場景說明：

一共壓測2000VUM，最大的并發(fā)數(shù)是10VUs，為了還原生產(chǎn)的場景，按階段性遞增進行壓測，一共壓測4分鐘，在1分鐘內(nèi)分3次過去逐漸增加并發(fā)數(shù)，由3.33VUs到6.66VUs，再到10VUs，演示流量逐漸慢慢增長，看一下CCU的彈性自動擴容能力。

以下是這次遞增壓測的結(jié)果報表，一共是576809個請求（接近6w個請求），沒有一個網(wǎng)絡(luò)請求失敗的，平均的響應(yīng)時間是在3.75ms，最高的并發(fā)數(shù)是在10VUs，下面的折線圖也是分為3次有規(guī)律的進行遞增。

舉例說明，我們設(shè)置了算力配置為：選擇最小最大規(guī)格為0.25核-1核：

從圖中可以看到，遞增壓測分為3波：

• 第一波初期的CCU在0.25左右，就會按0.25算力來進行計費
• 第二波的CCU在0.5左右，就會按0.25算力來進行計費
• 第三波業(yè)務(wù)高峰過來，CCU逐漸升高到0.691左右，就會按照0.69來進行計費，能夠很好的應(yīng)對業(yè)務(wù)負載。
• 在壓測結(jié)束后，CCU逐漸從0.5降到0.25，再到0，不使用就不計費

下圖可以看到我們在壓測產(chǎn)生的同時，CCU的費用也提高了，可以很方便的進行自動擴縮容，訪問量上來時自動擴容，降低時自動縮容，按照實際使用的資源付費，不使用不計費，如果沒有訪問，就不收費。

以下為CPU、內(nèi)存的性能數(shù)據(jù)參考，都是正比的增長趨勢，所以，上面講到的CCU的計費方式，跟CPU和內(nèi)存是有關(guān)系的。

八、自動擴縮容：

目標是做到秒級的擴縮容，并且期間對用戶是平滑的，無感知的。

以上圖為例子，用戶在購買時選擇最小規(guī)格為1核2G，最大規(guī)格為2核4G。

1. 如果是傳統(tǒng)的MySQL數(shù)據(jù)庫實例：

初始為1核2G，當業(yè)務(wù)訪問過來，把CPU用滿了時，用戶需要手動去修改規(guī)則，修改后需要重啟后才能生效。

2. 如果是TDSQL-C MySQL Serverless數(shù)據(jù)庫實例：

• 初始就給用戶提供最大CPU規(guī)格，內(nèi)存則從最小規(guī)格開始，假設(shè)用戶使用的CPU超過1核，并持續(xù)一段時間，將把內(nèi)存從2G擴到4G。
• TDSQL-C Serverless的CPU資源不會受限，可以在設(shè)置的最大規(guī)格內(nèi)任意使用。優(yōu)點是用戶性能不受限，引入的缺點是可能整機出現(xiàn)滿負載。
• 由于TDSQL-C采用存算分離架構(gòu)，一旦監(jiān)控到整機資源超過閾值，就進行快速遷移。遷移其實就是在另外一臺相對空閑的機器重新拉起實例，秒級完成。在資源負載上可以精準控制。

3. 創(chuàng)建壓測測試場景（使用80VUs）：

這里也是采用子遞增壓測的方式，但是之次使用最大的并發(fā)數(shù)為80VUs，在1分鐘內(nèi)全部壓測完，然后，在前30s使用40VUs，后面30s直接使用80VUS。

4. 壓測結(jié)果分析：

這里也是模擬一下，應(yīng)對于突發(fā)急劇增加的流量，TDSQL-C MySQL是如何進行擴容的。

• 第一區(qū)間是比如正常的業(yè)務(wù)流量，如下單購物，使用了并發(fā)40VUs，最大使用的算力差不多是0.8左右
• 第二區(qū)間是突然遇到雙11活動，業(yè)務(wù)的訪問量馬上急劇增加，這時候，TDSQL-C MySQL可以自動擴容到CCU接近4左右，可以完全滿足業(yè)務(wù)突增的情況
• 第三區(qū)間表示活動結(jié)束了，對應(yīng)的業(yè)務(wù)訪問量就降下來了，可以看到CCU也可以彈性的回收縮回到0.8左右
• 第四區(qū)間在沒有任何訪問量的時候，監(jiān)控服務(wù)會觸發(fā)計算資源的回收，此時，CCU降低到0，沒有使用，就可以不收費

從上圖，我們可以得出一個結(jié)論：

• 秒級的擴縮容，期間對用戶是平滑的，無感知
• Serverless 服務(wù)支持按實際計算和存儲資源使用量收取費用，不用不付費

由于壓測的并發(fā)數(shù)比較大，也可以看到TDSQL-C MySQL有一些診斷提示，我們也可以根據(jù)一些警告進行一些系統(tǒng)的優(yōu)化，以對應(yīng)業(yè)務(wù)的變化。

九、秒級擴容背后的架構(gòu)原理：

1. 主流公司的現(xiàn)有架構(gòu)：

很多公司目前的主流架構(gòu)是采用單體冗余架構(gòu)（一主多從），這種架構(gòu)在擴展性存在很大的問題。

• 實例的升降級和讀擴展，都需要通過數(shù)據(jù)搬遷來實現(xiàn)
• 隨著數(shù)據(jù)量不斷的增長，遷移耗時越來越長

2. 存算分離架構(gòu)：

為了解決一主多從架構(gòu)在擴展性這方面的問題，大多數(shù)采用的方案是采用存算分離架構(gòu)。

• 一類是ShareNothing架構(gòu)，計算和存儲均支持水平擴展，擴展能力非常強。但是最大的問題是SQL兼容性，需要不斷的持續(xù)構(gòu)建和完善自己的生態(tài)。
• 另一類是ShareStorage架構(gòu)，共享存儲架構(gòu)并沒有改變查詢引擎和ACI這些基礎(chǔ)特性，可以做到100%的兼容性。

騰訊云優(yōu)先選擇了基于共享存儲架構(gòu)的數(shù)據(jù)庫產(chǎn)品TDSQL-C提供Serverless服務(wù)。

TDSQL-C是騰訊云基于共享存儲架構(gòu)的云原生數(shù)據(jù)庫，由于ToB業(yè)務(wù)對穩(wěn)定性的要求很高，復(fù)用了云上比較成熟的組件。

• 在計算層使用騰訊維護的MySQL內(nèi)核分支-TXSQL，復(fù)用它的bugfix和新特性
• 在存儲層使用騰訊內(nèi)部的云硬盤CBS，把CBS的核心存儲和硬盤邏輯進行剖離，打造了統(tǒng)一存儲平臺HiSTOR

作為存儲底座，加上云硬盤CBS、云分布式文件系統(tǒng)CFS等多款云上的產(chǎn)品，提供副本同步、故障自動遷移、數(shù)據(jù)校驗等一系列完善的數(shù)據(jù)安全保障能力，這正是TDSQL-C MySQL Serverless產(chǎn)品能夠穩(wěn)定運行數(shù)年的重要基石。

十、 總結(jié)：

隨著云計算的發(fā)展，Serverless架構(gòu)帶來的優(yōu)勢，就是用戶不用更多的去考慮服務(wù)器的相關(guān)的運維工作，無需再去考慮規(guī)格大小、存儲類型、網(wǎng)絡(luò)帶寬的問題，Serverless架構(gòu)會幫助自動擴縮容、無需服務(wù)器運維了、無需備份數(shù)據(jù)、軟件配置等工作。

隨著 Serverless 概念的迅速普及，騰訊云數(shù)據(jù)庫TDSQL-C也推出了 Serverless 產(chǎn)品形態(tài)，可以為用戶提供更低成本、更靈活的云數(shù)據(jù)庫服務(wù)，減少了用戶維護數(shù)據(jù)庫規(guī)格的負擔。

通過上面對TDSQL-C Serverless 在自動擴縮容、按使用量計費、不使用不計費3個方面進行學(xué)習與探討，TDSQL-C Serverless在無負載時不產(chǎn)生任何費用，而當業(yè)務(wù)流量到來時能夠秒級自動擴容扛起突發(fā)請求，做到按使用量分配計算資源、按使用量進行扣除費用。

對于開發(fā)者和企業(yè)來說，Serverless 服務(wù)是騰訊云自研的新一代云原生關(guān)系型數(shù)據(jù)庫 TDSQL-C MySQL 版的無服務(wù)器架構(gòu)版，是全 Serverless 架構(gòu)的云原生數(shù)據(jù)庫。Serverless 服務(wù)支持按實際計算和存儲資源使用量收取費用，不用不付費，可以為企業(yè)很好的進行降本增效。文章來源地址http://www.zghlxwxcb.cn/news/detail-714008.html

到了這里，關(guān)于【騰訊云 TDSQL-C Serverless 產(chǎn)品體驗】基于TDSQL-C Serverless最佳實踐助力企業(yè)降本增效的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！