云计算的发展从IaaS，PaaS，SaaS，到最新的BaaS，FasS，在这个趋势中serverless(去服务器化） 计算资源发展Physical -> Virtualisation -> Cloud Compute -> Container -> Serverless。

---

一、背景介绍：

TDSQL-C 是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势，100%兼容 MySQL，为用户提供极致弹性、高性能、高可用、高可靠、安全的数据库服务。实现超百万 QPS 的高吞吐、PB 级海量分布式智能存储、Serverless 秒级伸缩，助力企业加速完成数字化转型。

Serverless 服务是腾讯云自研的新一代云原生关系型数据库 TDSQL-C MySQL 版的无服务器架构版，是全 Serverless 架构的云原生数据库。Serverless 服务支持按实际计算和存储资源使用量收取费用，不用不付费，将腾讯云云原生技术普惠用户。

Serverless特点：
1.自动驾驶（Autopilot）：
数据库根据业务负载自动启动停止，无感扩缩容，扩缩容过程不会断开连接。
2. 按使用计费（Utility Pricing）：
按实际使用的计算和存储量计费，不用不付费，按秒计量，按小时结算。

Serverless是什么？

无服务器计算是指开发者在构建和运行应用时无需管理服务器等基础设施，应用被解耦为细粒度的函数，函数是部署和运行的基本单位。用户只为实际使用的资源付费。平台根据请求自动平行调整服务资源，拥有近乎无限的扩容能力，空闲时则没有任何资源在运行。

Serverless有什么作用？

1. 低成本： (1). 运营成本：Serverless将用户的服务器，数据库，中间件委托于BaaS/FaaS，用户将不再参与基础设施及软件的维护。 (2). 开发成本：Serverless的架构中，用户操作的是服务化的组件比如存储服务，授权服务等，可以缩短开发周期，降低开发难度。
2. 按需计费： 按请求次数及运行时间，一方面可以最大程度利用资源，另一方面真正的按需计费可以降低用户的资源成本。
3. 弹性伸缩： (1). Serverless架构的优点即“横向扩展是完全自动的、有弹性的”。 (2). 在Serverless架构下，提供商将提供更细力度的计算能力最大限度满足实时需求，资源利用率将大幅度提升

---

二、传统云数据库在实际开发中的问题点：

大部分用户仍然处于云托管时代，传统云数据库帮助开发者实现高可用、自动备份，将云服务的特性提供给用户。

在传统云数据库上，在使用上是存在一些问题，主要分为以下四个：

1. 资源利用率低： (1). 计算和存储在一台机器上，CPU和磁盘使用不均衡。 (2). 例如CPU用满，但磁盘很空闲或者CPU很空闲但磁盘又满了，这样就会导致资源利用率低。 (3). 数据本地存储，随着业务的增长，单机存储量可能会大于单机磁盘容量限制，需要对业务进行迁移。 (3). 在低谷期资源浪费严重，高峰期不能及时扩容导致资源不足。
2. 扩展能力不足： (1). 在单机上可能不能满足一些用户要求，无法扩展。 (2). 受限于单机瓶颈，主从复制采用binlog，扩展性差。
3. 资源规划难： (1). 例如用户使用数据库，一开始无法预估这个数据库需要多少次磁盘空间。 (2). 固定规格，开发者需要提前发起扩缩容。 (3). 固定规格，计算进程常驻，无请求时依然收费。
4. 运维比较困难： (1). 因为每一个实例数据是私有的，所以每个实例都需要单独进行备份。 (2). 传统CDB架构的一主多备，备份迁移回档数据时会引发可用性和水平扩容等问题。 (3). 时刻关注业务负载变化而进行手动变配，增大运维、开发、测试等工作量。

传统云数据库在应对高峰值流量时，会遇到哪些困境？

传统云数据库在同机部署计算和存储的模式下，固定规格使得剩余资源难以利用。以双11高负载的场景为例，提前发起扩缩容的操作会导致运维效益随之大打折扣。不仅如此，固定规格对传统云数据库的计算进程常驻，无请求时仍然收费。

• 第一，为了避免数据库成为瓶颈，开发者可以按照波峰的方式进行部署。但工作负载不是始终都处于波峰，如果统一按照波峰位置部署数据库，就会带来资源浪费，提升成本。

• 第二，开发者可考虑按照波峰波谷的工作负载，配置一个平均值。这样成本的确有所节约，但问题是，一旦工作负载达到波峰，数据库将成为瓶颈，严重影响终端用户的体验。

• 第三，也是开发者现阶段最为常用的方式，即对不同指标进行监控，设置预警，比如设置当监测到 CPU 利用率到达 80% 的时候，系统发送告警信息，然后由开发或运维人员手动对数据库容量进行调整。尽管这样的方式的确可行，但却会耗费大量的时间成本。

---

针对以上业务出现的痛点和瓶颈，且看TDSQL-C Serverless是如何破局并有效的解决这些问题呢？

三、云原生数据库TDSQL-C：

传统架构的痛点

• 写性能受限:Master和Slave重IO写入，单条SQL RT(response time)较长
• 数据同步延迟高:主(多线程)从(单线程)写入线程数不匹配，高并发写入场景下主从延延迟严重
• 性能扩展效率低:不共享数据，单个MySQL升级规格(cpu、内存、磁盘)或增加Slave e 时需要搬迁数据，耗时长(1T数据耗时小时级别)
• 存储空间有限:存储空间受单台物理设备限制，基于文件的备份方案在大存储场景下效率低，例如10T数据量，备份时长达12+小时，且回档时间长
• 高可靠架构成本高:多节点架构,资源配置(cpu、内存、磁盘)需要成倍增加

如上是MySQL架构无法有效解决的固有问题，如需要解决，必须调整架构。存算分离架架构是有效解决 MySQL痛点最有效的方案之一。

在总体架构上，TDSQL-C是基于共享存储的存储和计算分离的架构，与传统的MySQL主备架构对比：

对比项	传统的MySQL	TDSQL-C
(1). 复制逻辑	传统的MySQL主备通过binlog进行逻辑复制	TDSQL-C通过redo日志进行的物理复制
(2). 存储数据方式	传统的MySQL需要向存储写多份数据包括data，binlog，redo log等	TDSQL-C只需向存储写一份redo日志即可
(3). 存储数据位置	传统的MySQL主备各存储一份数据	TDSQL-C基于共享存储只有一份数据

云原生数据库TDSQL-C计算存储分离架构的优势：

下图左侧可以看出在传统云数据库上，同一台机器部署的传统云数据库存储资源使用量达到了90%，而计算空余资源没有办法分配给新的租户从而造成资源浪费。同理，计算资源达到了90%，而存储空余资源没有办法分配给新的租户。

上图右侧TDSQL-C是采用计算和存储分离的架构，因此计算节点和存储节点之间的网络IO存在一定时延。而写事务提交时需要保证redo先刷盘才能完成提交，因此Redo日志刷盘存在网络IO。TDSQL-C在线程池的基础上进行了异步组提交优化，事务提交交给后台线程异步完成，将线程池资源提前释放从而能够去处理更多的请求。

云原生数据库TDSQL-C 高性能-plan cache：

TDSQL-C 高性能的一个重要优化是实现了查询计划缓存，称之为plan cache。左图中展示了一条SQL在数据库中的执行过程，会经过以下几个阶段：

一条SQL在数据库中的执行过程，会经过以下几个阶段：
(1). MySQL Server接受到用户的SQL请求。
(2). 在parse阶段解析为逻辑的执行计划树。
(3). 在查询优化阶段生成物理的查询计划。
(4). 执行器从存储引擎获取数据进行计算。

经过plan cache优化后，一条SQL执行过程省略了前面的解析和查询优化阶段，SQL的执行时间大大缩短了。优化后的效果(以sysbench场景为例)，不同颜色代表不同阶段的耗时，可以看到经过plan cache优化后，parse和查询优化时间减少了，性能提升了70%左右。

云原生数据库TDSQL-C 架构分析：

• 日志传输:计算节点只将物理日志(redol og)传输到存储节点，同时同步redo log 到slave 节点
• 可计算存储:存储层持久化日志、回放日志、持久化数据页面
• 只写redo 日志，整体IO减少60%以上， 典型场景写入性能提升90%以上
• 主从基于redo 高效同步与回放、Slave内存中回放redo log 生成数据页面，无需落盘，主从延迟降到ms级别
• 计算节点无状态，秒级升配、秒级增加slave
• 单计算节点可以实现高可用(无须备库)，可节省50%的计算节点成本
• 写入流程:
  

下图左侧图片描述，TDSQL-C是基于日志的数据库，计算机节点和存储节点之间有日志的传输，同时Master节点和TXStore存储之间也有redo日志传输，TDSQL-C将redo日志进行了压缩。

上图右侧图片描述，传统的MySQL的是通过binlog进行复制的。Binlog复制是在MySQL server层进行的，binlog记录的是逻辑的修改记录，binlog在备库apply需要经过server层的parser、optimizer后再经过engine的btree查找才能修改到对应的记录，这个路径比较长，复制速度慢。

而腾讯云TDSQL-C采用的是redo物理复制。Redo日志记录的是页面物理修改记录，redo复制是在engine层进行的，备库apply redo日志不需要查找就可以直接定位到页面，在内存中完成页面的修改，因此复制速度快。

更重要的一点是，TDSQL-C是基于共享存储的，主备数据物理上是一致的，而binlog复制只能保证逻辑一致。

基于全新架构HTAP能力

- 列存索引：基于列的数据存储和查询处理，与面向行的传统存储相比，最多可实现十倍以上的查询性能提升
-并行查询：摆脱传统MySQL单线程处理瓶颈，充分运用多核心硬件优势，实现多线程并行查询处理，最高可将查询速度提升十倍以上

使用场景列举：

Serverless极致弹性：

云原生数据库TDSQL-C的产品特点：

1. 架构分为计算层和存储层，一主多备。 (1). 计算主要负责原子性、一致性、隔离级别的实现，即ACID里ACI的实现。 (2). 存储主要负责数据持久化，主备之间通过 redo log 进行内存同步。 (3). 通过把计算和存储解耦以及引入新的数据同步协议，实现了 TDSQL-C。
2. 支持PB级存储。 (1). 传统数据库架构，购买规格和机器所用空间，一般单机磁盘容量是几T到几十T之间。 (2). TDSQL-C存储可直接连到网络存储，支持PB级存储。
3. 秒级扩缩容能力。 (1). 通过计算与存储解耦，存储空间可以自动扩缩容，弹性能力显著。(2). 存储容量可以自动扩充，且容量足够大，足以支撑业务的发展。
4. 秒级快照备份回档能力。 (1). 金融和游戏行业相关应用场景对备份的时效性和速度有较高的要求。 (2). 通过存储层秒级快照实现数据和redo日志的持续备份，提供任意时间点数据恢复能力（Point-in-time recovery，PITR) 。 (3). 最大程度降低主备延迟，能够解决数据的可靠性和可用性问题。
5. 支持serverless形态，按需计费。 (1). 传统数据库计费取决于本身购买的规格，以及使用所需要的时间。 (2). TDSQL-C 支持 serverless形态，支持按实际计算和存储资源使用量收取费用，不用不付费，整个服务监控力度达到秒级级别。 (3). 随着业务的增长，能够进行水平扩容，扩缩容的整体响应好。

---

四、TDSQL-C MySQL Serverless形态：

TDSQL-C MySQL 版提供 Serverless 服务以满足企业对特定业务场景的数据库服务要求，助力企业降本增效，以下介绍 Serverless 服务的几大特性。

自动启停：

Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。

通过监控去采集计算层的当前资源的情况，如果在设定好的时间内（如10分钟）还没有用户连接，会自动的回收这个计算层的资源。就如右边的图，没有计算层，只有存储层。只有数据，没有CPU和内存，此时，CCU就是0。存储量还是按实际的占用量进行计费。

TDSQL-C Serverless创新地引入了链接不断转发请求能力来解决这个问题。具体来说，在接入层加入一个恢复感知器 perceptron，来实现秒级冷启动。该方案的核心是通过perceptron和客户端握手后，先不断开链接，，在数据库实例恢复以后，与TDSQL-C握手，后续转发四层报文。

当用户访问进入接入层进行访问，接入层就会通知管控平台进行恢复，就把这个实例进行唤醒，又恢复成左边的图。这里有一个冷启动的时间，当第一次访问，到真正能把数据给到用户，目前是在2s内。

自动扩缩容：

不需要开发者提前去预测扩容的实例规格，通过系统的负载来进行自动的扩容。购买的时候，给用户提供一个区间，比如选择的是[1核2G, 2核4G]，就会只在这个固定的区间范围内进行扩缩容。

TDSQL-C Serverless服务的弹性策略一开始会根据用户购买时选择的容量范围，将 CPU、内存资源限制到最大规格，极大程度降低因 CPU 和内存扩容带来的时间影响和使用限制，即将蓝色矩形框的资源限制直接到最大规格2核4G的。

规格	图例	描述
1核2G低负载	第1个图	(1). 左侧轴表示CPU的资源，上方轴表示内存的资源，刚开始没有什么负载，CPU只有0.1核。 (2). Buffer pool(BP)是一个缓存，数据缓存到内存中更快的返回给用户，使用50%，就是1G。 (3). 其它内存包括一些用户连接数等一些内存占用了100M。
1核2G高负载	第2个图	(1). 遇到负载后，CPU立刻可以使用到1.8核。 (2). Buffer pool(BP)缓存还是1G。 (3). 其它内存包括一些用户连接数多起来了，使用了500M，超过了也不会产生OMM的现象。
2核4G高负载	第3个图	(1). 通过监控发现CPU使用率比较高的话，会相应的调整Buffer pool(BP)缓存到2G。 (2). 其它内存使用了500M。

当触发到自动弹性的负载阈值后，Buffer pool 会根据监控提前进行分钟级调整。在这个方案下用户使用数据库可以无感知进行 CPU 扩容，并且不会因为连接突增导致实例 OOM。

当负载下降时，就会进行缩容处理，可以看到在扩缩容的时候，其实是没有等待时间的，CPU可以马上用到最高，也可以立刻用到最低。对应的计费规则也是按照当前使用的资源来进行收费的。

这里要说一下，其它的厂商提供的一些方案。

规格	图例	描述
1核2G低负载	第1个图	(1). 蓝色矩形框是一个资源限制为1核2G，左侧轴表示CPU的资源，上方轴表示内存的资源，刚开始没有什么负载，CPU只有0.1核。 (2). Buffer pool(BP)是一个缓存，数据缓存到内存中更快的返回给用户，使用50%，就是1G。 (3). 其它内存包括一些用户连接数等一些内存占用了100M。
1核2G高负载	第2个图	(1). 遇到负载后，CPU立刻可以使用到100%，即达到1核。 (2). Buffer pool(BP)是一个缓存1G。 (3). 其它内存包括一些用户连接数多起来了，使用了500M。 (4). 遇到高负载持续1分钟，判定是要扩容的，才会把资源扩大到2核4G。
2核4G高负载	第3个图	(1). 蓝色矩形框是一个资源限制为2核4G。 (2). 扩容之后，CPU马上就会用到1.8核。 (3). Buffer pool(BP)是一个缓存2G，可以缓存到更多的数据，提供更好的性能。 (4). 其它内存使用了500M。

这种方能满足扩容的方案实现，但是有一个缺陷是从第2个图到第3个图是有一个监控时间的，需要触发到1分钟（不同的厂商不同的定义）才会去进行扩容，这段时间，用户的使用是受到制约的，CPU无法在短时间内用到更高，虽然已经购买了，但在这1分钟之内永远是1核。另外，如果其它内存超过了500M，就会出现OMM的现象，MySQL就会重启，就会对业务进行受损。

按使用量计费：

根据当前的负载去付费，而不需要还没使用到的资源去收费，每5秒进行一次资源使用的采样，包括CPU、内存、连接数等，Serverless 服务的弹性策略是利用监控计算层实现的。通过监控业务负载情况，系统对计算资源进行自动扩缩容，并对该时刻所消耗的资源进行计费。

CCU（TDSQL-C Compute Unit）为 Serverless 的计算计费单位，一个 CCU 近似等于1个CPU和2GB内存的计算资源，每个计费周期的 CCU 使用数量为：数据库所使用的 CPU 核数 与 内存大小的1/2 二者中取最大值。

突发大量访问：

传统架构服务在某些特殊场景下，可能出现大量的访问。为保证业务高峰时，系统能稳定运行，一般需要购买高性能、昂贵的服务器，组建集群负载均衡。但是，当业务回落时，就导致了大量服务器的资源浪费。

Serverless支持自动弹性伸缩，能根据业务访问量进行扩容、缩容，规避业务高峰系统异常的风险，可以从容应对诸如秒杀、节日活动等众多出现大量访问的业务场景。

总结：

相比传统数据库，云数据库Serverless有两个明显的优势，一是降低了数据库选型难度，用户不用再关心数据库选型，只需关心自身业务即可。二是减轻了DBA运维工作，云数据库Serverless可以根据流量洪峰自动弹性伸缩资源，为业务运行提供强有力的保障，大幅度减轻了DBA繁重的运维工作量，也在一定程度上降低了使用成本。

TDSQL-C Serverless可以根据用户业务负载，自动匹配相应资源，流量高峰来临，用户无须预估业务规模，从而花费大量精力去选型数据库，也不用考虑底层基础设施服务，真正实现按需付费，极大提升了资源利用效率。

---

五、实际体验与操作：

购买TDSQL-C MySQL Serverless数据库实例，这里提供了2种数据库版本的选择，分别为“MySQL 5.7”与“MySQL 8.0”，可以根据自己的自身的业务来进行实际的迁移，是100%兼容的。

算力是Serverless 的一个计算计费单位，Serverless 集群会在该范围内根据实际业务压力自动增加或减少 CCU。

自动暂停是指Serverless 服务在设定的时间内无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。

计费模式可以是按量计费（使用后再付费），也可以选择资源包(提前购买再使用，企业项目推荐使用)。

购买前会有一个提示，这里也说明了，Serverless是按照计算节点的费用和存储空间的费用加在一起来算的。

购买成功后，根据官方推荐有一个手册可以小试牛刀一下，本人对Python比较熟悉一点，所以就选择≤使用 Python 向 TDSQL-C 添加读取数据 实现词云图≥这个手册 ，跟着手册一步一步实现，很快就能完成作品。手册也是比较贴心和健全，比较适合新手一步到位。

根据活动的要求，需要对TDSQL的几个点做针对性的评测，接下来我们就来一起实际操作来感受一下Serverless的特性吧。

---

如何验证Serverless可以自动启停？

Serverless自动暂停的条件是无连接时实例会自动暂停，一般有2种方案可以实现Serverless的暂停。

触发类型	触发条件	触发性质
自动暂停	按照自动暂停设置的时间(如1小时)	被动
手动暂停	控制台上点击“暂停”按钮	主动

Serverless自动启动的条件是当有任务连接接入时，实例会秒级无间断自动唤醒，先找台服务器安装一下mysql，因为后面需要使用到mysql命令。

还需要将TDSQL-C MySQL Serverless的实例外网访问地址开启，才能让外网进行访问。

手动暂停Serverless服务器后，确认好服务器已经是“已暂停”状态。

使用以下统计mysql时间命令运行4次，看看效果如何。

date +"%T.%N" && mysql -u root -h bj-cynosdbmysql-grp-7sa8ssdy.sql.tencentcdb.com -P 26784 -pServerless123. -Nse "select 'resuming'" && date +"%T.%N"

可以看到基本上在1.4s左右就可以完成Serverless的数据库实例自动启动的连接。

---

如何验证Serverless可以自动扩缩容？

我们将按照以下5个步骤来进行验证，看看Serverless是否能够真的进行自动扩缩容，来满足我们不同流量的需求，减少运维的操作，达到一个降本增效的效果。

在购买时，我们选择的算力配置是0.5-4之间。

使用python提供一个接口，写入一些员工的信息，当然，这个Remark字段，我写的内容有点多，让Locust压测的时候，能够有点压力，顺便将代码部署到服务器上。

# 数据库的插入操作
    def insert_mysql(self, db):
        # 使用cursor()方法获取操作游标
        cursor = db.cursor()

        # SQL 插入语句
        sql = """INSERT INTO EMPLOYEE(FIRST_NAME,
                 LAST_NAME, AGE, SEX, REMARK)
                 VALUES ('xxxx', 'xxxx', 20, 'M', 'xxxx')"""
        try:
            # 执行sql语句
            cursor.execute(sql)
            # 提交到数据库执行
            db.commit()
        except:
            # 如果发生错误则回滚
            db.rollback()

        print("插入成功！！！！")

Locust是用Python实现的开源性能测试框架，不同于其他压测工具基于进程/线程产生压力，Locust是完全基于事件，支持分布式，一个Locust节点可以在一个进程中轻松支持上千并发用户。

以下是在压测过程中，看到CPU达到100%，去升级算力配置，最大改为32CCU，也就是32核64G的规格。

以下为升级配置后，数据库实例也是马上有了变化。

可以看到内存的趋势没有像CPU那么高的量，经过算力的配置升级，内存的使用率从6%缩减到2%。

以下为CCU整个算力的过程，可以看到从Locust压测开始不久就直接上升到最大的算力为4，并且持续了一段时间，这个时间就会按算力为4的费用来计费，当升级完算力配置后，CCU马上从4上升到CCU 11，这段时间就会按CCU 11来计费。

• CCU是可以弹性来扩容的，从0到2，到后面的4，再到11，可以根据业务的压力来弹性不同的规格来处理。
• 升级完算力配置后，可以马上弹性为新的配置，可以有效的解决流量过高时遇过的瓶颈。

六、展望与总结：

在云计算时代，不同业务形态对高弹性、高可用性、可扩展性的需求越来越强，在此背景下，云数据库采用Serverless架构，能在高性能之上提供降低成本的更优解。

腾讯云新一代云原生数据库TDSQL-C Serverless ，采用了创新的“存算分离”架构，具备100%兼容MySQL、超百万QPS性能、多线程并行查询、一体化HTAP、金融级容灾等多种核心特性，可为用户提供极致弹性、高性能、高可用、高可靠、安全的数据库服务。同时，该版本还提供了集群版Serverless，支持只读节点和Proxy弹性能力。该架构的升级也丰富了Serverless当前的应用场景，使TDSQL-C Serverless得以全面承载核心业务场景。

TDSQL-C Serverless数据库应用阶段，其具备完全自动化的扩容能力，它能够随着用户业务的请求数的增加和减少，智能化“膨胀”和“缩小”，实现资源的自动“吞吐”。

TDSQL-C可帮助用户进一步压缩存储成本，尤其适用于低频访问业务、开发测试、营销活动等常见应用场景。当前，业内的Serverless无法完全做到不使用不付费，实例暂停后的存储费用仍较高昂，可释放存储则将彻底解决这一问题，当实例暂停后，数据会归档存储，其存储成本同比分布式存储最高可降低80%。

腾讯云TDSQL-C Serverless的极致性能、极致弹性、极致成本的企业级云数据库服务，助力各行各业对特定业务场景的数据库服务要求，助力企业降本增效。