一、引言：

隨著云計算技術(shù)的不斷發(fā)展，越來越多的企業(yè)開始選擇將自己的數(shù)據(jù)庫部署在云上，以更好了的支持企業(yè)數(shù)字化轉(zhuǎn)型以及業(yè)務創(chuàng)新，在這個過程中，很多客戶會遇到這樣一個問題，業(yè)務會存在高峰期和低谷期，同樣數(shù)據(jù)庫的訪問量也是會存在相應的高峰期和低谷期。

傳統(tǒng)的數(shù)據(jù)庫服務并不能很好的解決這個問題，只能依賴反復的人工升降配，即不安全穩(wěn)定，又會造成額外的IT運維成本以及人力資源成本，因此在客戶的強烈的降本增效呼聲之中，騰訊云TDSQL-C MySQL Serverless數(shù)據(jù)庫應運而生。

借助《騰訊云TDSQL-C聯(lián)合CSDN產(chǎn)品測評活動》，讓我們來深入了解并實踐一下TDSQL-C MySQL Serverless數(shù)據(jù)庫，利用產(chǎn)品的資源用量低、簡單易用、彈性靈活和價格低廉等優(yōu)點和特性，賦能業(yè)務合理優(yōu)化使用成本，創(chuàng)造價值，進一步助力企業(yè)降本增效，為國產(chǎn)云數(shù)據(jù)庫點贊，遙遙領(lǐng)先。

二、TDSQL-C MySQL Serverless數(shù)據(jù)庫：

TDSQL-C MySQL Serverless數(shù)據(jù)庫是騰訊云針對中小型企業(yè)或個人開發(fā)者推出的一款數(shù)據(jù)庫，提供了CPU、內(nèi)存的實時彈性能力，構(gòu)建云架構(gòu)下的數(shù)據(jù)庫產(chǎn)品新形態(tài)。

1. 什么是Serverless？

Serverless無服務器架構(gòu)是基于互聯(lián)網(wǎng)的系統(tǒng)，其中應用開發(fā)不使用常規(guī)的服務進程。相反，它們僅依賴于第三方服務（例如騰訊云Serverless Framework服務），客戶端邏輯和服務托管遠程過程調(diào)用的組合。

云計算的發(fā)展從IaaS、PaaS、SaaS，到最新的BaaS、FasS，在這個趨勢中Serverless(去服務器化）越來越明顯，隨著容器技術(shù)，IoT，5G，區(qū)塊鏈等技術(shù)的快速發(fā)展，技術(shù)上對去中心化，輕量虛擬化，細粒度計算等技術(shù)需求愈發(fā)強烈，未來Serverless將在云計算的舞臺上大放異彩。

云計算經(jīng)歷了從 IaaS -> PaaS -> Serverless/FaaS 的發(fā)展歷程，下面對這些概念做一些基本介紹。

總結(jié)的說，從IDC → IaaS，用戶不用關(guān)注真實的物理資源。從IaaS → PaaS，用戶不再關(guān)注操作系統(tǒng)，數(shù)據(jù)庫，中間件等基礎(chǔ)軟件。從PaaS → BaaS/FaaS, 用戶可以很少甚至不用關(guān)注后臺。Serverless是云計算發(fā)展到一定階段的必然產(chǎn)物：

• “綠色”計算（最大程度利用資源，減少空閑資源浪費）
• “低門檻”技術(shù)（成本低，包括學習成本及使用成本）

2. TDSQL-C MySQL Serverless數(shù)據(jù)庫實例的優(yōu)勢：

與普通MySQL數(shù)據(jù)庫實例相比，TDSQL-C MySQL Serverless數(shù)據(jù)庫實例有如下6點明顯的優(yōu)勢：

TDSQL-C MySQL Serverless數(shù)據(jù)庫可以根據(jù)業(yè)務負載自動擴縮容實例，開發(fā)者無需關(guān)心底層資源問題，支持自定義自動暫停時間，在業(yè)務不間斷情況下實現(xiàn)秒級冷啟動，提供多種靈活計費方式供用戶選擇。

Serverless計費方式無需按固定資源付費，按照實際使用量進行收費，不使用不付費，根據(jù)業(yè)務負載自適應動態(tài)匹配資源，秒級彈性升降資源與計費，助力企業(yè)降本增效，最高可降低成本90%。

3. 生活場景闡述區(qū)別：

以在學校時，看過的一篇小說場景來進行闡述傳統(tǒng)數(shù)據(jù)庫與TDSQL-C MySQL Serverless數(shù)據(jù)庫直觀的對比，從生活中的實際場景來描述，從而更容易理解，從而選擇合適的產(chǎn)品。

每一年的國慶節(jié)假已經(jīng)來臨，2位主角安排了自己的旅游出行，由于雙方家庭經(jīng)濟基礎(chǔ)不一樣，所以，對于出行的安排也是會有區(qū)別的。

4. 總結(jié)：

TDSQL-C MySQL Serverless數(shù)據(jù)庫實例提供計算資源按需計費的能力，具有資源用量低、簡單易用、彈性靈活和價格低廉等優(yōu)點，賦能用戶面向業(yè)務峰谷時對計算能力進行快速且獨立的擴縮要求，做到快速響應業(yè)務變化的同時，合理優(yōu)化使用成本，進一步助務企業(yè)降本增效。

三 、TDSQL-C MySQL Serverless數(shù)據(jù)庫服務特性：

TDSQL-C MySQL 版提供 Serverless 服務以滿足企業(yè)對特定業(yè)務場景的數(shù)據(jù)庫服務要求，助力企業(yè)降本增效。

1. TDSQL-C MySQL Serverless的總體架構(gòu)：

Serverless 服務是騰訊云自研的新一代云原生關(guān)系型數(shù)據(jù)庫 TDSQL-C MySQL 版的無服務器架構(gòu)版，是全 Serverless 架構(gòu)的云原生數(shù)據(jù)庫。Serverless 服務支持按實際計算和存儲資源使用量收取費用，不用不付費，將騰訊云云原生技術(shù)普惠用戶。

上圖為TDSQL-C MySQL Serverless的總體架構(gòu)，核心模塊為中控節(jié)點（svls scheduler）。中控節(jié)點接收計算層采集的內(nèi)存/CPU/訪問情況等監(jiān)控數(shù)據(jù)，根據(jù)策略決定是否擴縮容，啟停實例，以及按照計費規(guī)則上報云控制臺計費。

TDSQL-C MySQL Serverless有faker模塊，暫停計算節(jié)點時會把四層的vip:vport綁定到faker端口，用戶請求過來后，識別為有效的MySQL協(xié)議，則通知中控模塊將實例重新拉起，其優(yōu)點在于用戶不需要為代理節(jié)點付費。

2. 資源擴縮范圍（CCU）：

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

2.1 CCU是啥？

CCU（TDSQL-C Compute Unit）為 Serverless 的計算計費單位，一個 CCU 近似等于1個CPU和2GB內(nèi)存的計算資源，每個計費周期的 CCU 使用數(shù)量為：數(shù)據(jù)庫所使用的 CPU 核數(shù) 與 內(nèi)存大小的1/2 二者中取最大值。

Serverless 服務需要設(shè)定彈性范圍，詳細彈性范圍區(qū)間可參考 算力配置。

2.2 MySQL實例資源選擇：

通過TDSQL-C MySQL Serverless實例資源的算力配置，最低可選擇0.25CCU，代表0.25的CPU以及0.5GB內(nèi)存，最高可選擇64CCU，代表64的CPU以及128G的內(nèi)存，足以應付很多場景的覆蓋。

建議在第一次設(shè)置彈性范圍時，最小容量配置為0.25 CCU，最大容量選擇較高的值。較小的容量設(shè)置可以讓集群在完全空閑時最大限度地進行縮減，避免產(chǎn)生額外的費用，較大的容量可以在集群負載過大時最大限度地進行擴展，穩(wěn)定度過業(yè)務峰值。

通過指定實例資源波動的上下限，以CCU作為單位，讓數(shù)據(jù)庫服務變的更加靈活，切實的幫助企業(yè)達成降本增效的目標 。

3. 彈性策略：

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

3.1 傳統(tǒng)Serverless架構(gòu)中的自動擴縮容方案：

下圖左側(cè)傳統(tǒng)Serverless架構(gòu)中會有一個共享的虛擬機池，里面存放的是不同大小的規(guī)格，假設(shè)需要從1核2G擴大到2核4G，則從池子里面找到2核4G的虛擬機，將對應的數(shù)據(jù)盤掛載到虛擬機，并將訪問切到該虛擬機，即可完成自動擴容。

傳統(tǒng)Serverless架構(gòu)中自動擴容存在的問題點：

3.2 傳統(tǒng)TDSQL-C Serverless架構(gòu)中的自動擴縮容方案：

而上圖右側(cè)TDSQL-C Serverless架構(gòu)中，用戶在購買時選擇最小規(guī)格為1核2G，最大規(guī)格為4核8G。TDSQL-C Serverless會在初始就給用戶提供最大CPU規(guī)格，內(nèi)存則從最小規(guī)格開始?？梢钥闯?，TDSQL-C Serverless的CPU資源不會受限，可以在設(shè)置的最大規(guī)格內(nèi)任意使用。優(yōu)點是用戶性能不受限，引入的缺點是可能整機出現(xiàn)滿負載。

基于以下兩點，TDSQL-C Serverless可以很好應對自動擴縮容：

3.3 小結(jié)：

Serverless 服務的彈性策略是利用監(jiān)控計算層實現(xiàn)的。通過監(jiān)控業(yè)務負載情況，系統(tǒng)對計算資源進行自動擴縮容。

4. 自動啟停：

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

當沒有數(shù)據(jù)庫請求時，監(jiān)控服務會觸發(fā)計算資源的回收，并通知接入層。當用戶再次訪問時，接入層則會喚醒集群，再次提供訪問。

5. 計費模式：

Serverless 服務通過監(jiān)控業(yè)務負載情況，系統(tǒng)對計算資源進行自動擴縮容，并對該時刻所消耗的資源進行計費。

6. 存儲資源包的誤區(qū)：

在使用過程中，發(fā)現(xiàn)一個存儲資源包的相關(guān)問題，有段時間沒有使用，在收取存儲資源的費用，記得當時明明已經(jīng)購買過存儲的資源包了，這么快就用完了嗎？記憶中好像用的數(shù)據(jù)量也不多。

查看TDSQL-C MySQL Serverless實際的使用存儲量為224.57GB，但是我購買的是40TB的存儲資源包，為什么這么快就用完了呢？

以下是購買資源包的列表，發(fā)現(xiàn)存儲資源包已經(jīng)滿了。

因為不知道是什么原因?qū)е碌?，只能無奈去提一個工單來詢問一下是什么問題。

以下為騰訊云工程師給的回復，40T的存儲資源包，而現(xiàn)在已使用的存儲為0.2T，每天是24小時，按照他給的公式，表示8天左右就會使用完。

看來是自己理解錯誤了，結(jié)論是存儲資源包會按照每小時實際使用的存儲量進行抵扣收費 ，在購買的時候，選擇計費模式的時候，上面也有備注。

四、TDSQL-C MySQL Serverless自動啟停實驗：

1. MySQL數(shù)據(jù)庫連接原理：

MySQL 服務端實例啟動后，就可以通過客戶端建立與服務端的連接，然后發(fā)送查詢/更新請求了。

2. 可視化圖形工具客戶端連接數(shù)據(jù)庫：

先將TDSQL-C Serverless服務器關(guān)掉，再在Navicat For MySQL填寫完Host、Port、User Name、Password后，點擊“Test Connection”后，可以看到服務器的實時監(jiān)控，發(fā)現(xiàn)有連接進來后，馬上把服務器進行恢復。因為沒有有效的記錄時間的方案，只能看折現(xiàn)圖，可以發(fā)現(xiàn)Threads進程是在23時48分15秒左右馬上啟動起來了。

3. MySQL二進制文件的兩種連接方式：

Linux平臺環(huán)境下主要有兩種連接方式，一種是TCP/IP連接方式，另一種就是socket連接：

• 通過TCP/IP連接MySQL實例時，MySQL會先檢查一張權(quán)限表，用來判斷發(fā)起請求的客戶端IP是否允許連接到MySQL實例，該表就是MySQL庫下面的user表。
• UNIX Socket連接方式其實不是一個網(wǎng)絡(luò)協(xié)議，所以只能在MySQL客戶端和數(shù)據(jù)庫實例在同一臺服務器上的情況下使用。

因此，本次測試會采用MySQL TCP/IP的方式進行測試。

可以使用shell腳本來操作TDSQL-C MySQL Serverless數(shù)據(jù)庫自動啟停，使用-e參數(shù)可以執(zhí)行各種sql的(創(chuàng)建、刪除、增、刪、改、查)等各種操作。

3.1 時間命令time的shell腳本：

腳本的作用是當數(shù)據(jù)庫暫停后，第一個mysql連接是模擬登錄到Serverless數(shù)據(jù)庫，出現(xiàn)自動啟動數(shù)據(jù)庫，看看時間是多久，然后，馬上再次用mysql連接模擬一下在數(shù)據(jù)庫啟動的狀態(tài)下，需要多久進行連接。

#!/bin/bash
# 數(shù)據(jù)庫信息
HOSTNAME="gz-cynosdbmysql-grp-69gvou9h.sql.tencentcdb.com"
PORT="25950"
USERNAME="root"
PASSWORD="Mydb123."

# 執(zhí)行查詢數(shù)據(jù)
query_sql="SHOW VARIABLES LIKE 'version';"
time mysql -h${HOSTNAME}  -P${PORT}  -u${USERNAME} -p${PASSWORD} -e "${query_sql} -vvv"
time mysql -h${HOSTNAME}  -P${PORT}  -u${USERNAME} -p${PASSWORD} -e "${query_sql} -vvv"

mysql -v參數(shù)的作用，為了防止SQL本身執(zhí)行時間影響到連接的效果，可以把SQL執(zhí)行的時間也打印出來。

● 若要同時顯示語句本身：-v
● 若要增加查詢結(jié)果行數(shù)：-vv
● 若要增加執(zhí)行時間：-vvv

3.2 時間命令date的shell腳本：

#!/bin/bash
# 數(shù)據(jù)庫信息
HOSTNAME="gz-cynosdbmysql-grp-69gvou9h.sql.tencentcdb.com"
PORT="25950"
USERNAME="root"
PASSWORD="Mydb123."

# 執(zhí)行查詢數(shù)據(jù)
query_sql="SHOW VARIABLES LIKE 'version';"
firstStart=$(date +%s.%N)
mysql -h${HOSTNAME}  -P${PORT}  -u${USERNAME} -p${PASSWORD} -e "${query_sql}" -vvv
firstEnd=$(date +%s.%N)
firstRunTime=$(echo "$firstEnd - $firstStart" | bc)
echo "第一次首連命令執(zhí)行時間：$firstRunTime 秒"

secondStart=$(date +%s.%N)
mysql -h${HOSTNAME}  -P${PORT}  -u${USERNAME} -p${PASSWORD} -e "${query_sql}" -vvv
secondEnd=$(date +%s.%N)
secondRunTime=$(echo "$secondEnd - $secondStart" | bc)
echo "第二次連接命令執(zhí)行時間：$secondRunTime 秒"

4. 準備兩臺不同配置的機器：

評測的目標機器為TDSQL-C Serverless，使用的模式為按量收費，機房的位置在廣州四區(qū)。

準備兩臺測試機器，一臺是騰訊云的CVM云服務器，2核4G 10Mps，廣州七區(qū)與Serverless實例在同一個區(qū)，一臺是華為云耀云服務器2核2G 3Mps，華北北京四區(qū)，測一下不同服務器、不同區(qū)域的結(jié)果做比較。

騰訊云的CVM云服務器，可以通過orcaterm進行遠程登錄，可以進行如下的測試腳本執(zhí)行流程：

# 復制腳本
vi query.sh
# 增加執(zhí)行權(quán)限
chmod -R 777 query.sh
# 執(zhí)行shell腳本
./query.sh
# 檢查是否有mysql
mysql
# ubuntu安裝mysql客戶端
apt-get install -y mysql-client-core-8.0

5. 測試腳本分析實驗數(shù)據(jù)：

通過2種查看linux執(zhí)行時間的命令的shell腳本，每次執(zhí)行前，先將服務器進行暫停，腳本中第1個mysql命令表示服務器暫停時默認啟用，看一下執(zhí)行的時間多久，這里需要注意的是因為SQL本身也會存在執(zhí)行時間，比如執(zhí)行一個慢查詢，這里為了得到比較合理的值，增加了-vvv參數(shù)來輸出SQL命令本身執(zhí)行的時間，得到的公式：

命令的總執(zhí)行時間 – SQL本身執(zhí)行的時間 = Serverless服務器自動啟動時間

每個腳本分別在2臺云服務器騰訊云CVM、華為云云耀云服務器各執(zhí)行5次，得出以下結(jié)果：

• 可能由于騰訊云服務器與Serverless在相同的區(qū)域廣州機房，時間略比華為云服務器要短。
• 基本上在2s左右就能完成Serverless服務器自動啟動。

云服務器(Cloud Virtual Machine，CVM)是騰訊云提供的可擴展的計算服務。使用云服務器避免了使用傳統(tǒng)服務器時需要預估資源用量及前期投入，幫助在短時間內(nèi)快速啟動任意數(shù)量的云服務器并即時部署應用程序，推薦應用在部署時，參考以下方案：

6. Java代碼連接MYSQL數(shù)據(jù)庫方式：

JDBC是Java數(shù)據(jù)庫連接(Java Database Connectivity)，是一套用于執(zhí)行SQL語句的Java API。應用程序可以通過這套API連接到關(guān)系型數(shù)據(jù)庫，并使用SQL語句完成對數(shù)據(jù)中數(shù)據(jù)的查詢、增加、更新和刪除等操作。

JDBC在應用程序與數(shù)據(jù)庫之間起到了一個橋梁作用，當應用程序使用JDBC訪問特定的數(shù)據(jù)庫時，需要通過不同數(shù)據(jù)庫驅(qū)動與不同數(shù)據(jù)庫進行連接，連接后即可對該數(shù)據(jù)庫進行相應的操作。

采用的邏輯是先將Java代碼啟動并且連接上數(shù)據(jù)庫，這時候，程序設(shè)定延遲1分鐘，此時，手動在服務器控制臺進行暫停服務器后，再讓程序進行SQL的操作，看看實際生產(chǎn)的一個真實情況能不能滿足？

Java核心的代碼：

@Component
public class Service implements ApplicationContextAware {
    @Autowired
    private ShopMapper shopMapper;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        try {
            Thread.sleep(60*1000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        // 第一次首次連接(Serverless服務器自動觸發(fā)啟動)
        long firstStartTime = System.currentTimeMillis();
        System.out.println("SQL語句執(zhí)行前時間：" + firstStartTime);
        shopMapper.insertTest();
        long firstRunTime = System.currentTimeMillis()-firstStartTime;
        System.out.println("第一次總耗時："+ firstRunTime);
        // 第二次連接
        long secondStartTime = System.currentTimeMillis();
        System.out.println("SQL語句執(zhí)行前時間：" + secondStartTime);
        shopMapper.insertTest();
        long secondRunTime = System.currentTimeMillis()-secondStartTime;
        System.out.println("第二次總耗時："+ secondRunTime);
    }
}

執(zhí)行結(jié)果：

• 項目啟動時，要對數(shù)據(jù)庫進行了實例化連接
• 程序啟動后，會有一個60s的延遲設(shè)置，此時，手動暫停Serverless實例，模擬在程序啟動后，在一定時間內(nèi)不使用，Serverless服務器實例自動暫停
• 第一次連接，觸發(fā)Serverless恢復感知器自動啟動服務器，可以看到在3.127s就完成了
• 第二次連接，Serverless已經(jīng)恢復了，可以看到在0.089s內(nèi)完成操作

6. 小結(jié)：

通過3種MySQL客戶端連接方式的進行測試，TDSQL-C MySQL Serverless自動啟停實驗，可以完全滿足生產(chǎn)環(huán)境的需求。

五、TDSQL-C MySQL Serverless彈性伸縮實驗：

下面將按照以下5個大的步驟進行對TDSQL-C MySQL Serverless的一個壓力的測試過程。

為了可以有效的進行測試觀察結(jié)果，TDSQL-C MySQL Serverless選擇了一個較大的算力彈性區(qū)間范圍[1，32]，即最小可以是1核2G的云數(shù)據(jù)庫服務器(可能會更小，0.1都可能存在)，最大可能是32核64G云數(shù)據(jù)庫服務器。

通過對壓測的結(jié)果進行分析，TDSQL-C MySQL Serverless在不使用的時候，就會釋放計算節(jié)點，只收取存儲的費用。當服務器啟動后，就會再加上計算節(jié)點的CCU費用，可以看到TDSQL-C MySQL Serverless在最開始的算力為1，可以隨著壓測的流量變大，同步增加到最大32個算力，當壓測停止后，又自動在后面縮容到算力到0為止。

以下為分3個階段進行TDSQL-C MySQL Serverless的測試，第一步本地進行多進程可以看到?jīng)]有太多的變化，第二步使用本地JMeter，由于機器配置的原因，也是沒有到達一個極限，最后第三步，在購買一臺高配的云服務器使用Jmeter壓測，可以達到實例的一個滿核的負載。

以下為從監(jiān)控平臺得到壓力測試這段時間內(nèi)，得到各個指標參數(shù)的值，這里沒有把每一分鐘的變化值羅列出來，只是把一些波動變化比較大的值，在以下進行列舉：

通過以上的指標數(shù)據(jù)，我們把他放到echats中去查看，因為內(nèi)存使用量的值比較大，就不參與計算，通過對11：50到12：50這一個小時壓測得到的指標數(shù)據(jù)，可以形成以下折現(xiàn)圖。

option = {
  title: {
    text: 'TDSQL-C Serverless CCU趨勢圖'
  },
  tooltip: {
    trigger: 'axis'
  },
  legend: {
    data: ['CPU使用率', '內(nèi)存的使用率', 'CCU算力值', 'Direct', 'Search Engine']
  },
  grid: {
    left: '3%',
    right: '4%',
    bottom: '3%',
    containLabel: true
  },
  toolbox: {
    feature: {
      saveAsImage: {}
    }
  },
  xAxis: {
    type: 'category',
    boundaryGap: false,
    data: ["11：50", "11：59", "12：03", "12：05", "12：08", "12：09", "12：10", "12：11", "12：15", "12：16", "12：18", "12：19", "12：20", "12：21", "12：27", "12：28", "12：29", "12：32", "12：33", "12：34", "12：37", "12：38", "12：39", "12：40", "12：41", "12：46", "12：48", "12：50"]
  },
  yAxis: {
    type: 'value'
  },
  series: [
    {
      name: 'CPU使用率',
      type: 'line',
      stack: 'Total',
      data: ["1.04", "3.77", "5.41", "6.38", "8.36", "10.68", "15.12", "23.08", "33.33", "43.13", "37.91", "59.37", "65.51", "58.39", "97.81", "91.53", "100", "91.61", "100", "87.61", "1.79", "1.81", "0.93", "0.55", "0.31", "0.02", "0", "0"]
    },
    {
      name: '內(nèi)存的使用率',
      type: 'line',
      stack: 'Total',
      data: ["0.98", "1.73", "3.89", "3.89", "3.89", "7", "8.87", "15.09", "18.08", "34.1", "35.29", "35.29", "52.72", "79.58", "80.35", "80.35", "80.36", "80.37", "80.37", "80.37", "58.81", "35.05", "15.68", "7.42", "3.39", "1.98", "0", "0",]
    },
    {
      name: 'CCU算力值',
      type: 'line',
      stack: 'Total',
      data: ["1", "1.21", "1.73", "2.04", "2.68", "3.42", "4.84", "7.39", "10.67", "13.8", "12.25", "19", "24.81", "27.89", "31.3", "29.29", "32", "29.32", "32", "28.04", "27.89", "12.3", "6.2", "3.14", "1.43", "1", "0", "0",]
    },
  ]
};

• 前期CPU和內(nèi)存都在成正比增長的趨勢，CCU也是一個成正比的趨勢
• 后期CPU急劇下降，而內(nèi)存的降低幅度沒那么快，CCU是與CPU和內(nèi)存一起有關(guān)聯(lián)的，可以看到CCU的折線在CPU與內(nèi)存折線之間

在TDSQL-C MySQL Serverless達到波峰的時候，CPU達到100%，順便測試了一下查詢語句，還是能夠很快速的訪問并得到結(jié)果，只要項目中沒有大量的慢查詢，項目估計還是可以正常的運行的。

六、公司業(yè)務導入TDSQL-C MySQL Serverless可行性分析：

公司的業(yè)務是做定制化車險的，在創(chuàng)業(yè)前期大多采用與第三方機構(gòu)合作，快速驗證商業(yè)模式，用以迅速打開市場。

隨著業(yè)務體系的逐漸完善，公司也慢慢的導入自研的體系，以下是公司可回溯系統(tǒng)的建設(shè)體系，對比TDSQL-C MySQL Serverless數(shù)據(jù)庫對比的場景優(yōu)化思考。

(1). 回溯的場景周期較短，剩余時間不使用也要付費：

開發(fā)的某類產(chǎn)品分為投保期和理賠期，投保期一般為2-3個月，等到承保期后，就不再使用了，就是理賠的階段，這樣來看，目前也是按照包年模式來購買的數(shù)據(jù)庫，這樣會造成資源的過剩，應該是周期性的資源購買。

(2). 歸檔后，只有少量的異常案例需要回溯，使用率不高：

可以省出計算節(jié)點的費用，只單純的使用存儲量的費用，如果進一步集成COS，可能費用會再一次壓縮與縮減。

Serverless數(shù)據(jù)庫其它的應用場景：

由于傳統(tǒng)企業(yè)通常已經(jīng)預置了大量軟硬件資源，以及用戶使用習慣不易改變等因素，Serverless數(shù)據(jù)庫在傳統(tǒng)企業(yè)現(xiàn)有業(yè)務中的采用將需要一定的過程，但在以下一些新興行業(yè)企業(yè)或新興業(yè)務場景，Serverless數(shù)據(jù)庫正在快速展現(xiàn)其優(yōu)勢，并占據(jù)重要位置。

七、總結(jié)：

TDSQL-C MySQL Serverless數(shù)據(jù)庫實例不僅提供網(wǎng)絡(luò)資源、命名空間、存儲空間的垂直資源隔離能力，還提供計算資源按需計費的能力，具有資源用量低、簡單易用、彈性靈活和價格低廉等優(yōu)點，賦能用戶面向業(yè)務峰谷時對計算能力進行快速且獨立的擴縮要求，做到快速響應業(yè)務變化的同時，合理優(yōu)化使用成本，進一步助務企業(yè)降本增效。

在業(yè)務波動較大的場景下，普通數(shù)據(jù)庫實例和TDSQL-C MySQL Serverless數(shù)據(jù)庫實例資源使用和規(guī)格變化情況，可以看出普通實例在波谷期浪費的資源較多，在高峰期資源不足會導致客戶業(yè)務受損，而TDSQL-C MySQL Serverless數(shù)據(jù)庫實例憑借其極致的彈性，完美的支持了客戶不同時段的業(yè)務負載，并且在最大程度上避免了資源的浪費，節(jié)省了大量的成本。文章來源地址http://www.zghlxwxcb.cn/news/detail-730335.html

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