【腾讯云 TDSQL-C Serverless 产品体验】TDSQL-C MySQL Serverless助力企业降本增效直播读后感_serverless数据库

同时，《全球Serverless架构市场》报告预计全球Serverless架构市场的规模预计到2024年将达到140亿美元，市场的前景非常广阔。

目前公司也是在停留在云原生数据库时代，如下为本人负责的产品线所使用的MySQL主从实例的样本。

1.5 分析传统的云数据库的业务痛点：

先思考一下，传统云数据库存在哪些问题点呢？使用Serverless能够解决哪些业务的痛点呢？

传统的云数据库一般是计算和存储往往都在一台单机服务器实例上，因此很难按照等比例的方式去使用数据库，因为计算的比例和存储的比例可能是任何组合方式：

• 计算使用率低只有10%，但是存储使用率达到90%，虽然计算的资源很宽裕，但是存储的资源已经不够用了，所以，只能进行横向扩展机器。
• 计算使用率高达到了90%，但是存储使用率低只有10%，虽然存储的资源很宽裕，但是计算的资源已经不够用了，也只能进行横向扩展机器。

总结来看，传统的云数据库很难做到Serverless的特性，因为很难做到一个弹性伸缩的能力，因为两种资源类型都是在同一台物理机上，可以看到存算一体的架构很容易造成很大的资源浪费和产生碎片。

1.6 主从同步延迟问题：

主从同步是通过Binlog去进行主从的数据同步，延迟也会很高，横向扩展机器的耗时也会更长。

主要原因有以下几点:

• 主库写入事务到二进制日志需要时间,而从库是通过拉取日志进行同步的。
• 主从复制通道传输二进制日志需要时间。
• 从库接受、解析日志并写入需要时间。
• 一定情况下主库执行的复杂查询也会延迟提交事务。
• 网络传输本身都会有一定的延迟。
• 主从数据库服务器与硬件差异也会导致差异。

1.7 业务应对突发流量解决方案：

• 在固定规格下的云数据库实例，在一些突发的场景下，如双11、双12、618的活动，需要提前去扩容服务器的资源，以最大的资源来保证业务的稳定性。
• 在进程常驻的状态下，假如资源不使用也是要去进行收费。
• 目前很大的用户量都是采用这种云数据库方式来进行业务的部署，需要提前购置扩容这部分资源，以达到预计的负载上限，来保证流量可以稳定的运营。
• 在这样的同机资源部署下，最大的问题就是剩余资源是很难以利用的。

1.8 云原生数据库TDSQL-C Serverless的发展必然性：

TDSQL-C Serverless是采用TDSQL-C云原生数据库的底座，最大的特点就是做了存算分离，资源不是在同一台物理机上。同时，使用的是Redo log的方式去同步，极大的降低了Binlog主从同步延迟概率的情况。

• 如果存储不够时，只需要增加存储相关的资源即可，因为存储是分布式池化的存储。
• 如果计算资源不足了，就只需要纵向增加计算节点。

可以很好的进行Serverless化，Serverless化的特点就是哪部分资源不够，就加哪部分资源。

• 在存算分离的架构下，不会产生碎片，合理化的分配计算和存储的资源。
• 同时，采用一个预置的纵向弹性规格，不需要再去提前进行扩缩容，自动的帮助用户去提高计算节点、加大存储资源。
• 自动启停的功能，可以让资源不使用就不进行收费
• 秒级横向的进行扩容

1.9 Serverless主要为了解决哪些诉求：

各行各业都在力求提高自己的敏捷性，以便更快的创新和响应变化。企业需要更快速的构建应用程序、快速扩展、支持百万用户、服务全球毫秒级响应，并且能够处理产生的 PB 甚至 EB 级的数据，最后还要支持业务的三高特性（高弹性、高需求和高可用），企业在构建这些应用时会面临一系列的挑战。

2. TDSQL-C Serverless架构介绍：

TDSQL-C提供了两种形态的产品：

• 正常的normal形态
• 一种是基于Serverless演进的3.0数据库时代，Serverless时代云原生数据库

2.1 正常的normal形态TDSQL-C MySQL的优势：

不兼容MySQL5.6，老版本的客户需要注意一下。

TDSQL-C MySQL 版（TDSQL-C for MySQL）是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势，为用户提供具备高弹性、高性能、海量存储、安全可靠的数据库服务。TDSQL-C MySQL 版100%兼容 MySQL 5.7、8.0。实现超百万级 QPS 的高吞吐，最高 PB 级智能存储，保障数据安全可靠。

TDSQL-C MySQL 版采用存储和计算分离的架构，所有计算节点共享一份数据，提供秒级的配置升降级、秒级的故障恢复，单节点可支持百万级 QPS，自动维护数据和备份，最高以GB/秒的速度并行回档。

TDSQL-C MySQL 版为用户提供具备超高弹性、高性能、海量存储、安全可靠的数据库服务，可帮助企业轻松应对诸如商品订单等高频交易、伴随流量洪峰的快速增长业务、游戏业务、历史订单等大数据量低频查询、金融数据安全相关、开发测试、成本敏感等的业务场景。

2.2 TDSQL-C Serverless架构分析：

TDSQL-C Serverless架构独特的亮点：

• 在接入层增加一个恢复感知器，用恢复感知器来做连接的保持，可以控制实例的暂停与启用。
• 如果当管控层监控到没有负载，快速的将计算节点进行回收并暂停实例，回收节点是由管控层来操作的。
• 如果马上有访问连接进来，首先会访问恢复感知器，恢复感知器在管控层进行一个交互，再去唤醒计算层节点，立马会拉起计算节点。
• 通过管控组件去监控负载，发起扩缩容的动作。

增加了一个恢复感知器，用来保证实例在暂停后能快速去恢复起来。同时，保证首连是不断的。

2.3 恢复感知器验证：

购买一台TDSQL-C MySQL 5.7 Serverless的数据库实例，实例形态一定要选择“Serverless”，这里选择“北京三区”的主可用区。

下面会讲到Serverless的集群版本，所以，这里选择Serverless的“集群版本”，算力配置读写实例最小是0.25，最大是8的CCU，只读节点也是相同的配置。计费模式的话，计算节点和存储节点都选择按量计费模式。

填写完一些参数值后，就可以实例化一台Serverless的数据库实例出来了。

开启读写实例与只读实例的外网访问权限。

开启完读写实例与只读实例的外网访问权限，就会得到对应的主机名和端口号。

购买一台测试使用的4核8G云服务器用于mysql连接时间和sysbench压测场景。

安装MySQL数据库。

wget https://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm
rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
yum -y install mysql-server
1
2
3

# 暂停服务器后，触发Serverless读写实例服务器自动启动
time mysql -h bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com -P24637 -uroot -pxxxx < sql.sql
# Serverless读写实例服务器启动后，查看连接时间
time mysql -h bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com -P24637 -uroot -pxxxx < sql.sql
1
2
3
4

当暂停Serverless服务器后，使用mysql连接的方式，去触发Serverless读写实例服务器自动启动，可以看到花了1.215s就完成了自动启动。再次连接花了0.047s，表示后续的连接也是可以正常使用的。

# 暂停服务器后，触发Serverless只读实例服务器自动启动
time mysql -h bj-cynosdbmysql-grp-qny06yxq.sql.tencentcdb.com -P20835 -uroot -pxxxx < sql.sql
# Serverless只读实例服务器启动后，查看连接时间
time mysql -h bj-cynosdbmysql-grp-qny06yxq.sql.tencentcdb.com -P20835 -uroot -pxxxx < sql.sql
1
2
3
4

当暂停Serverless服务器后，使用mysql连接的方式，去触发Serverless只读实例服务器自动启动，可以看到花了5.906s就完成了自动启动，这个要比读写实例要花费更久的时间，再次连接花了0.043s，表示后续的连接也是可以正常使用的。

并行自动启动验证：

当暂停Serverless服务器后，开启2个终端工具，分别使用mysql连接的方式，同时去触发Serverless读写实例服务器自动启动。

可以看到2个终端都触发了Serverless自动启动功能，前者使用了1.269s就完成了自动启动，后者使用了1.016s完成了自动启动，这样可以表示，自动启动是可以并发去完成的。也可以防止在项目中因为并发启动而导致问题。

当暂停Serverless服务器后，开启2个终端工具，分别使用mysql连接的方式，同时去触发Serverless只读实例服务器自动启动。

可以看到2个终端都触发了Serverless自动启动功能，前者使用了5.939s就完成了自动启动，后者使用了5.618s完成了自动启动，这样可以表示，自动启动是可以并发去完成的。也可以防止在项目中因为并发启动而导致问题。

手动暂停Serverless服务器，马上进行自动启动测试：

当暂停Serverless服务器后，马上进行多次mysql的连接，看看TDSQL-C MySQL Serverless是会马上自动启动吗?

当暂停Serverless服务器后，马上执行第一个mysql进行连接，可以看到第一个窗口执行了0.040s，第二个窗口执行了2.694s，说明在第一次时，还是走的接入层，而第二次是服务器暂停后，马上处罚了自动启动功能，走的是恢复感知器。

在暂停Serverless服务器时，多点击几次会有一个报错提示。

3. 应对负载不定场景下的弹性能力：

3.1 常见Serverless厂商的弹性方案：

大部分常见的Serverless厂商的弹性方案，在创建的时候，提前给一个标识好的规格，当负载的瓶颈达到一定预设置的值后，再将触发分配第二个阶段的规格的实例，这样做会存在很大的弊端：

• 比如，刚开始是1核2G的规格，当CPU和内存达到它设定的预设值上限了，并不会立即触发弹性的。
• 会存在一个监控的时长，比如持续30s内的CPU消耗都要达到预设值，才会去触发扩容2核4G的规格。
• 一般来说，负载都是比较瞬时、特别快的流量，监控的时长过长很有可能会造成，没有及时扩容上去，导致服务器宕机或造成OMM的现象，都是有可能的。
• 所以，TDSQL-C摒弃了这种有弊端的方式。

3.2 TDSQL-C Serverless极致纵向弹性：

TDSQL-C Serverless采用资源最大化提供，提前把资源最大的规格上限提供，这部分资源都预置给用户：

• 比如购买的时候的范围是最小是1 CCU，最大是8 CCU。
• 在启动实例时，会直接把8 CCU的规格资源全部都预置给用户。
• 在运行的过程，会根据CPU负载去动态调整buffer，这样的话，就不会发生流量瞬时进来之后，导致没有办法及时弹起来的情况。

总结，TDSQL-C Serverless会把资源最大化的提供给用户，瞬时能够做到满载，更像是“事前弹性”的弹性方式。

3.3 TDSQL-C Serverless几个技术要点：

• 规格弹性，需要用户在一开始购买的时候，选择规格的空间，购买后会在这个规格空间中随时做一个纵向的弹性。
• 同时，按CPU与内存按最大规格供给能够保证资源是最大化的。
• 用的时候，就可以及时的弹起来，理论上，CPU与内存不存在扩容时间。
• 能够根据监控做到秒级扩缩容。

3.4 集群级Serverless一主多从是如何做横向的弹性：

集群级Serverless一主多从的架构，资源细粒度更高，各节点可独立弹性：

• 增加了RO节点的Serverless弹性，现在更多用的是RW的一个Serverless弹性云能力，就是读写节点的。
• 支持多种组合，Serverless RW + Serverless RO，normal的RW + Serverless RO，可以组合不同的资源混部组合节点部署，去更大的丰富业务场景。
• 在实际的场景中，读写节点对于很多用户来说业务可能更关键，所以更希望用normal版本TDSQL-C来保证业务的稳定性，normal RW结合Serverless RO的节点，这样做的情况下，资源力度可以做到更高，每个节点也可以做到独立的弹性。

集群级Serverless一主多从的架构，数据库proxy代理能够进行读写分离，进行负载均衡：

• 因为节点可以扩容做纵向的弹性，通过负载还可以做横向弹性。
• 假如现在整个Serverless RO的负载达到80%，会通过proxy会再拉起一个Serverless RO的节点。
• 所有整个集群集的连接，都会通过proxy来做连接保持的能力，同时，通过proxy去做负载均衡，能够保证负载不高的场景下，也可以回收节点。

举个数据库proxy代理的场景：

• 所有的弹性Serverless RO节点的负载都不到20%，这个时候，就会通过proxy根据负载均衡，把新的连接打到老的节点上，把待回收的节点逐步做一个释放的动作，直到待回收的节点负载降到0为止，就会把这个节点进行回收。
• 内部是有一个调度器去全面的分析每个节点的资源使用情况，保证资源的合理使用，在最下面是归档存储，这也是Serverless独特的特点。

3.5 Serverless读写分离架构sysbench测试：

需要注意的是，只读节点是不能写入数据。

只写场景(oltp_write_only)：

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_write_only prepare

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 --events=0 --time=600 --threads=500 --percentile=95 --report-interval=1 oltp_write_only run

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_write_only cleanup 
1
2
3
4
5

准备造需要的数据。

测试的时候，遇到报错：Too many connections

在TDSQL-C MySQL Serverless控制台的参数设置中，找到“max_connections”值，并将其由80改为100000。

接着测试中又发现报错：Can’t create more than max_prepared_stmt_count statements(current value: 16382)，修改“max_prepared_stmt_count”参数，由16382改为1048576。

清理测试数据。

只读场景（point select）：

这里需要说明一下，写入测试数据是在读写库，但是测试在只读库。

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_only prepare

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-qny06yxq.sql.tencentcdb.com --mysql-port=20835 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 --events=0 --time=600  --threads=500 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=1 oltp_read_only run

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-qny06yxq.sql.tencentcdb.com --mysql-port=20835 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_only cleanup
1
2
3
4
5

只读库测试的时候，发现又出现了Too many connections，难道读写库和只读库是2套参数配置吗？

在参数设置中，确实能看到有2套的参数设置，同理，找到“max_connections”值，并将其由80改为100000。修改“max_prepared_stmt_count”参数，由16382改为1048576。

如果想要看读写库与只读库共同的折线图，可以多选2种实例即可。

混合读写场景（point select）：

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_write prepare

sysbench --db-driver=mysql  --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 --events=0 --time=600  --range_selects=0 --threads=500 --percentile=95 --report-interval=1 oltp_read_write run

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_write cleanup
1
2
3
4
5

混合读写场景（range select）：

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=txy123.. --mysql-db=sysbench_db --table_size=20000 --tables=150 oltp_read_write prepare

sysbench --db-driver=mysql  --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=txy123.. --mysql-db=sysbench_db --table_size=20000 --tables=150 --events=0 --time=600   --threads=500 --percentile=95 --report-interval=1 oltp_read_write run

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.com --mysql-port=24637 --mysql-user=root --mysql-password=txy123.. --mysql-db=sysbench_db --table_size=20000 --tables=150 oltp_read_write cleanup
1
2
3
4
5

4. 弹性伸缩过程中的稳定性保证：

4.1 最核心的特点是经常性的做弹性，在弹性的过程中，是如何去保证服务的稳定性呢？

首先在不用实例的时候，会对实例做一个暂停的动作，当使用的时候，再把实例拉起来，这就是恢复感知器的作用，对外官宣用户首连登录成功时长是小于2000ms的。

4.2 如何做到的连接不断，秒级启动的能力？不断首连又是如何实现的？

• 通过恢复感知器，首先当连接进来，会通过TCP握手的方式去跟恢复感知器做一个鉴权，会做一个信息的交换。
• 恢复感知器感知到外面有连接进来之后，它会立马通知管控恢复实例，跟管控层也会建立一个TCP的握手的信息。
• 管控层在接收到连接进来之后，立马通知计算层，要去恢复了，立马去恢复计算节点，再去跟接入层做访问。

4.3 如果在接入层增加恢复感知器这个模块，会不会导致访问的IO变长？

• 是不会导致访问IO变长的。
• 这里会存在一个vip的路由权重，去精准的进行接入。
• 如果实例是属于暂停状态下，首次访问，会通过恢复感知器进行访问。
• 当实例一旦拉起来之后，这里的VIP权重设为0，新的访问会直接打到计算节点上，这样保证了后面所有的连接，能够像正常访问数据库一样，不需要再去通过恢复感知器，极大程序减少损耗。
• 如果用proxy去做这个事情，会变的很重，时间也会变的很长，所以，就是能够做到2000ms内的技术特点。

4.4 为什么在缩容的过程中，会出现毛刺呢？如何保证在弹性的过程中是稳定的？

在之前使用的过程中，发现一个问题，对性能要求比较高的客户，在使用的过程中，在缩容过程中，会发现毛刺，这里指的是超过100ms的慢查询。

在扩缩容的过程中，主要发现有3个瓶颈：

• 1. 在缩容过程中，需要去刷脏，这时候，需要持久化page页，会存在IO瓶颈。
• 2. 第二瓶颈就是在回收过程中，用reset bp逻辑，缩容过程中需要多次遍历free list和lru list链表，遍历过程中持有mutex锁，如果一旦访问的数据到了待回收区，有可能这个mutex锁时长会可能较长。
• 3. 一旦时间比较长的话，就会出现慢查询的情况，也有可能需要获取全局bp锁，全局BP锁获取执行时间比较长的话，也是容易产生毛刺，总体来说，就是在待回收区，需要回收BP Chunk区域，从回收区到非回收区的整个过程中，可能会经常遇到需要做遍历，遍历可能需要持锁，导致出现慢查询的问题。

4.5 如何去解决在扩缩容的过程中存在的3个瓶颈？

IO的瓶颈的解决方案：

• 因为本身的技术架构是采用TDSQL-C架构模式，采用redo log的方式，在存储层去异步生成page。
• 所以，计算节点不需要进行刷脏的，可以直接丢弃淘汰page，不存在IO瓶颈，这是TDSQL-C本身独特的原因。

MUTEX锁如何优化？

• 把持锁的范围和时长进行减少，现在是改成了按地址遍历回收区的chunk中的block。
• 不再是多次循环去遍历free list和lru list链表，同时在加锁区间由整个的lru链表变成单个block。
• 这是MUTEX锁瓶颈的解决办法。

全局锁瓶颈如何优化？

• 全局锁通过2个模式，一个是延迟释放chunks，同时需要提前预分配chunks。
• 通过这2种方式，再同时优化resize hash算法，改为异步模式。
• 整个从回收区到非回收区不再需要多次的去遍历LRU链表，这是一个最核心的。
• 不需要多次去遍历了，所以，可以解决掉BP毛刺的问题。

通过以上的几种方式，现在毛刺的数量是下降到100%，整个缩容过程中，也不会存在毛刺的现象。

5. 极致成本助力企业降本增效：

5.1 如何通过计费来帮助企业进行有效的去降低成本？

计费的模式：

• 采用CCU的单位去进行计费。
• CCU的计算逻辑就是取CPU和二分之一内存的最大值。
• 如果CPU消耗的是1，内存消耗是3G，就是取1和1.5的规格的最大值，就是1.5，每5s进行一个采样频率，5s平均消耗的CCU，会被计为当前时间段所消耗的使用量，可以按实时的CCU去进行一个计费。
• 通过右边的折线图，CPU使用的核数，内存使用的量，通过这2个值去进行交集的计算，可以得到每秒CCU的量进行付费。

CCU的付费模式提供2种：

• 一种是后付费模式，根据使用量进行收费。
• 另一种是预付费模式方案，提供资源包的付费方式，资源包可以简单理解为储蓄卡，就像一张电卡，我把体验的资源事先储蓄到电卡里面，抵扣电卡里面的度数，这是资源包的逻辑。

对比同规格包年包月刊例价最高降低25%，资源包的方式也是为了福利企业和用户使用的计费方式。

5.2 灵活的计费方式：

以下为在整个测试过程中，所产生的费用，也是根据你的弹性CCU来计算的，当然还有存储的费用。

从上面的账单可以发现一个规律，所有的存储费用是产生在读写实例上，只读库可以共享数据。读写库和只读库都是分别单独进行费用收费的。

当然，也可以像前面提到的购买资源包的方式来进行绑定到实例上，可以近一步的节省费用。

5.3 如何做到可释放存储，进一步压缩存储成本呢？

很多业内不使用就不收费，去帮助用户降低成本，都是去降低计算节点的成本。

现在对于腾讯云来说，当实例暂停之后，也是在收取用户的存储费用，下一步，真的要做serverless化的话，不仅要降低计算成本，不使用不收计算的费用，同时，存储的费用也应该尽可能的压缩，包括做到极尽不去收用户的钱。

5.4 归档存储池，极致成本压缩：

这部分是在的底部架构做了一个归档存储池，现在都是用共享分布式存储池，采用删副本形式。

• 当实例暂停之后，会把整个实例的数据都会去进行一个归档，归档的存储成本要更低，简单理解，等同于cos。
• 最大的难点就是帮助恢复过程中，当访问请求进来之后，如何快速的去访问数据。
• 如果访问的A表，优先的把A表的数据往共享存储池进行恢复，同时，B、C、D表也会进行一个异步的恢复。
• 如果用户访问B表，优先会把B表的访问恢复去提前
• 这样会导致在访问过程中，可以随时的去访问数据，不需要等所有的数据全部恢复到共享分布式存储池中，才能去访问存储数据。

这种方式能够保证当实例暂停之后，数据都能及时做一个归档，这样可以进一步尽量去压缩存储成本，经过计算归档存储成本最高可降低80%的存储费用。

6. 典型应用场景：

6.1 上面分别对Serverless的几个特点进行了分析，那什么样的场景适合使用Serverless呢？

有低频访问的业务，个人博客、论坛、微信小程序、云开发、微信云托管，这部分是低频访问，不需要去购买一个比较大的规格放在那里，有可能平时都不怎么使用，Serverless很适合低频访问的业务场景。

其次，就是开发测试环境，这部分场景有很大的共性，比如周一至周五工作时间使用，周未包括下班时间不使用，针对这一部分，就可以不使用不收费，对Serverless也是很好的应用场景。

再者，就是活动类的场景，比如说一些大促，这种活动或游戏突然会成为一个暴品，不及时进行一个低延扩容操作，很有可能导致负载跟不上，节点直接就打爆，serverless本身具有自动弹性的能力，所以，无需关心提前做一个扩容的能力，同时，也不需要为额外的资源去进行付费，当高负载来了之后，可以立马瞬时的弹到一个比较大的规格，这部分是很适合活动类的场景。

6.2 典型的2种客户案列：

如果做微信开发，包括微信小程序，对微信云托管比较熟悉，微信云托管现在采用MySQL的数据库，就是TDSQL-C Serverless所支撑的，目前已经为接近50万小程序开发者提供了一站式开发云服务，使用Serverless云服务器的方式，能够即使即用，能够快速的去使用，快速的去分配数据库资源，发布的速度也很快，如果实际体验微信云托管资源的话，如果想要使用数据库的话，可以他的创建资源时间差不多在2s内，就可以立马帮你分配一个数据库实例。

另外一个腾讯乐享平台，是一个社区平台，很大的特点就是因为大部分的用户都是比较小的客户，可能用的规格最大也不会超过1核2G，在这样的规格下面，如果给每个用户都去分配一个实例的话，导致资源浪费特别严重，而且还有很多僵尸实例，他们就采用把所有用户都归纳到一个实例上面去，通过不同的用户去访问不同的库，去做这样的一个访问，但是这样会导致很差的隔离性，同时，也会有安全性的危险，使用Serverless可以很好的去帮助乐享平台解决针对很多小用户，不经常使用的业务场景，帮助腾讯乐享降低成本80%以上。

在之前的公司（因为是外包需要快速出活的原因），接触了微信云托管的应用，当时，记得最大的特点就是开箱即用、按量来收费，非常适合个人和中小型业务公司来使用，比较意外的是，原来云数据也是可以按量来收费，目前接触的公司业务都是包年来购买的。

6.3 例举Serverless各行各业的应用场景：