【腾讯云 TDSQL-C Serverless 产品体验】饮水机式使用云数据库

云计算的发展从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进行逻辑