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

本人接触互联网也有差不多10个年头，从个人的博客、商城、电商、教育、淘宝客等，手里大大小小的项目也不在少数，接触过的技术栈也是比较多，从.***、php、java、go、python等都有涉猎，接触的规模也是逐渐由小到大，从简单的单机应用部署到SOA架构，再到目前公司业务的K8S集群，助力企业降本增效是每个公司都在倡导的，公司专门还发起了“提案改善”的降本增效活动，号召大家一起助力企业降本增效。

通过这次《TDSQL-C MySQL serverless助力企业降本增效》的直播学习，可以了解TDSQL-C是如何实现超百万 QPS 的高吞吐、PB 级海量分布式智能存储、Serverless 秒级伸缩。希望可以借此找到契机，为公司的业务助力企业降本增效，同时也是感谢陈老师的精彩分享。

本文将从四个方面进行TDSQL-C MySQL Serverless的探讨，通过观看老师的讲解，结合自我的认知，来分析TDSQL-C MySQL Serverless如何来进行助力企业降本增效。

主要探讨的内容：

• 1. 探讨什么是Serverless？包括Serverless目前的市场现状是什么样子？有什么价值？
• 2. TDSQL-C Serverless是如何去设计的，架构是什么？
• 3. 分三种场景模式阐述TDSQL-C Serverless在用户使用过程中，如何保证Serverless在弹性的过程中，保证服务的稳定性、帮助企业做降本增效。
• 4. 实际的典型应用场景分析如何给企业或用户带来的价值。

1. 数据库Serverless市场现状：

1.1 什么是Serverless?

传统意义的Serverless是一种云服务提供的方式，是Faas + Baas的一种服务形态。

• Faas和Baas的共同特点就是以API的形式提供服务，好处是按照调用次数来进行收费，如果不使用就可以不进行收费。
• API形式的调用还可以实现更好的实时弹性的伸缩，不用太关心服务器的运维工作，只需要“使用”这个方法即可。

1.2 Serverless 是一种云原生开发模型：

• 允许开发人员构建和运行应用程序而无需管理服务器。
• Serverless 并不意味着不需要服务器。
• 只是服务器由云厂商提供服务器的维护，更新，扩展等无差异化的服务器管理的日常工作。

1.3 Serverless工作模式：

开发人员可以将其代码简单的打包部署在无服务器，最大化利用云的弹性可扩展性构建自己的应用程序。

1.4 Serverless技术热度逐渐升温：

传统的企业在进行数字化转型的同时，要将以前的单体式应用进行微服务化。然而，这波未平、下波技术的热潮又来了，现在各大云厂商如腾讯云都在投入重大精力去做serverless（无服务器）服务，云计算正在经历从IAAS —> PAAS —> SAAS —> BAAS&FAAS的过渡。

云数据库也是经过了三个时代的发展，到现在的Serverless数据库可以提供了自动弹性能力、更智能化的运维，极致的成本优化方案，备受大家的关注。

• 1.0时代主要是最大程度的降低了用户投入很多人力去使用复杂的运维工作，包括物理机资源的一个损耗的情况。
• • 2.0时代主要追求更极致的性能优势，进入一个云原生的数据库时代，最典型的特点是存算分离，能够充分的利用资源，给用户提供更高的性能，更充分的去发挥云计算特点与优势。
  • • 3.0时代主要追求的是更加极致的资源利用率、更加极致的成本，更加轻和智能化运维。

同时，《全球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的***U，只读节点也是相同的配置。计费模式的话，计算节点和存储节点都选择按量计费模式。

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

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

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

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

安装MySQL数据库。

wget https://dev.mysql.***/get/mysql57-***munity-release-el7-8.noarch.rpm
rpm --import https://repo.mysql.***/RPM-GPG-KEY-mysql-2022
yum -y install mysql-server

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

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

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

当暂停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 ***U，最大是8 ***U。
• 在启动实例时，会直接把8 ***U的规格资源全部都预置给用户。
• 在运行的过程，会根据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.*** --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.*** --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.*** --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_write_only cleanup 

准备造需要的数据。

测试的时候，遇到报错：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.*** --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.*** --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.*** --mysql-port=20835 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_only cleanup

只读库测试的时候，发现又出现了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.*** --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.*** --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.*** --mysql-port=24637 --mysql-user=root --mysql-password=xxxx --mysql-db=sysbench_db --table_size=20000 --tables=200 oltp_read_write cleanup

混合读写场景（range select）：

sysbench --db-driver=mysql --mysql-host=bj-cynosdbmysql-grp-2bgu5xfe.sql.tencentcdb.*** --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.*** --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.*** --mysql-port=24637 --mysql-user=root --mysql-password=txy123.. --mysql-db=sysbench_db --table_size=20000 --tables=150 oltp_read_write cleanup

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 如何通过计费来帮助企业进行有效的去降低成本？

计费的模式：

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

***U的付费模式提供2种：

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

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

5.2 灵活的计费方式：

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

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

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

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各行各业的应用场景：