【腾讯云 TDSQL-C Serverless 产品体验】TDSQL-C MySQL Serverless助力企业 ...

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

---

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

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

主要探讨的内容：
  

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

  

---

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的CCU，只读节点也是雷同的设置。计费模式的话，盘算节点和存储节点都选择按量计费模式。

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

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

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

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

安装MySQL数据库。

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

复制代码

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

复制代码

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

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

1. 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
3. 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
5. 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

复制代码

准备造必要的数据。

测试的时间，碰到报错：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）：

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

1. 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
3. 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
5. 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

复制代码

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

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

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

混合读写场景（point select）：

1. 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
3. 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
5. 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

复制代码

混合读写场景（range select）：

1. 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
3. 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
5. 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

复制代码

   

---

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

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

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

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

   

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

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

   

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

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

         在之前利用的过程中，发现一个标题，对性能要求比较高的客户，在利用的过程中，在缩容过程中，会发现毛刺，这里指的是高出100ms的慢查询。
     在扩缩容的过程中，主要发现有3个瓶颈：
   

• 
  
  • 在缩容过程中，必要去刷脏，这时间，必要持久化page页，会存在IO瓶颈。
    
  
  
• 
  
  • 第二瓶颈就是在回收过程中，用reset bp逻辑，缩容过程中必要多次遍历free list和lru list链表，遍历过程中持有mutex锁，假如一旦访问的数据到了待回收区，有可能这个mutex锁时长会可能较长。
    
  
  
• 
  
  • 一旦时间比较长的话，就会出现慢查询的环境，也有可能必要获取全局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各行各业的应用场景：

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。