一、业务增长MySQL带来的业务痛点分析：
1. 性能瓶颈：
- 随着公司的业务快速发展，数据库中的数据量猛增，访问性能也变慢了，单台MySQL实例无法应对和满足大规模数据管理和请求访问，导致数据库性能下降，成为瓶颈。
- 关系型数据本身就比较容易形成系统瓶颈，无论是从单机存储容量、连接数、处理能力都有限。
- 当单表的数据量达到1000W以后，由于查询和操作的维度较广，哪怕使用了MySQL从库读写分离、优化索引等操作时，性能还是无可避免严重下降。
2. 数据强一致性同步延迟：
- 当架构增加Redis、RabbitMQ等消息队列
- OLTP的大数据量统计数据类异构表同步只能满足业务的T+1
- 系统架构中，异步设计方案中的中间件故障，导致数据重传、数据丢失
二、数据库应用的类型：
| Item | 区分 | OLAP | OLTP |
|---|---|---|---|
| 1 | 名称 | 在线分析处理(Online Analytical Processing) 在线事务处理 | (Online Transaction Processing) |
| 2 | 作用 | 处理企业级的决策分析、战略分析以及业务分析等 | 处理企业级的常规业务操作，如公司的采购、销售、存储、支付等 |
| 3 | 侧重点 | 多维数据分析技术和聚合算法，方便分析数据 | 强调数据的精确、事务的原子性和并发性 |
| 4 | 数据类型 | 历史性、汇总性、非实时性、不可变性数据 | 实时的、明细的、实时性的、可变性数据 |
| 5 | 场景 | 数据仓库 | 常规业务操作 |
| 6 | 查询模式 | 采用复杂的算法和存储结构，如多维数据库和立方体结构 | 需要简单的SQL语句，如基本的、事务相关的查询 |
| 7 | 性能要求 | 更高的存储要求和处理能力 | 快速且稳定的响应速度，可扩展性和高可用性 |
| 8 | 应用场景 | 企业级的决策支持和战略分析等领域 | 采购、销售、库存管理、银行交易等领域，极短的时间内快速响应用户请求，从而保证业务的正常运行 |
所以，在日常的企业级应用中，OLAP和OLTP针对不同的业务场景，有不同的解决方案。OLAP主要用于企业级决策和战略分析，需要快速的数据查询和分析技术。相反，OLTP主要用于企业日常操作，需要快速的数据更新和处理技术。
三、项目中的优化手段之《分库分表》：
1. 业务痛点：
- 由于数据量过大而导致数据库性能降低的问题
2. 解决的问题：
- 优化单一表数据量过大而产生的性能问题，使得单个表的数据量变小，提高检索性能，一定程度上可以缓解查询性能瓶颈
- 避免IO争抢并减少锁表的几率
- 解决业务层面的耦合，业务清晰
- 能对不同业务的数据进行分级管理、维护、监控、扩展等
- 高并发场景下，在一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈
- 有些系统中使用的“冷热数据分离”，备份历史库
- 在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈
3. 带来新的问题：
- 跨库join（安全性等方面考虑，一般是禁止跨库join的）
- 分布式事务
- 业务复杂度增加
- 投入的硬件成本也会更高
- 跨分片的复杂查询，跨分片事务等
- 跨节点关联查询
- 跨节点多库进行查询时，limit分页，order by排序问题，就变得比较复杂
- 主键避重，主键值ID无法保证全局唯一
- 公共表、参数表、数据字典表等都是数据量较小，变动少，每个数据库都保存一份
四、TDSQL-C MySQL Serverless解决的痛点：
TDSQL-C MySQL Serverless实例提供了CPU、内存的实时弹性能力，构建云上资源架构下的MySQL产品新形态。
1. 常规业务下的痛点：
| Item | 业务方案 | 业务痛点 | Serverless实例解决方案 |
|---|---|---|---|
| 1 | 自建MySQL实例 | (1). 需要购买大量的云服务器构建MySQL集群，设备成本费用高 (2). 专人运维成本，部署业务 (3). 双11等活动时，提前负责服务的扩缩容 | (1). 按量收费，不使用不收费 (2). 云函数计算，从CI/CD到服务部署，扩缩容，全部自动完成，客户可以更专注于业务代码 |
| 2 | 传统的云数据库 | (1). 提供多种内存/CPU规格给用户购买 (2). 用户只能按最大负载量购买满负载配置，即使没有使用到，也需要为选中的规格付费 | (1). 自动扩缩容，访问量上来时自动扩容，降低时自动缩容，用户不需要关注规格 (2). 按照实际使用的资源付费 (3). 不使用不计费，如果没有访问，不应该收费 |
2. Serverless数据库特点：
举个场景：如果自己想要出行就只能购买汽车、摩托车，现在可以直接通过滴滴等第三方平台使用打车服务，只需输入目的地即可，不需要再关注买车的坑、开车怕被撞和汽车保养的问题，核心诉求得到了更好的满足。
Serverless数据库可以看做，直接在云上直接购买虚拟机，部署业务，负责服务的扩缩容，从CI/CD到服务部署，扩缩容，全部自动完成，用户只需要更专注于业务代码即可。
Serverless数据库的基本特点是无需运维、以API方式提供服务、按实际使用计费、无使用无费用等。
3. 在业务波动较大的场景下，普通实例和Serverless实例资源使用和规格变化情况如下图所示：
由上图可以看到，在业务波动较大的场景下：
| Item | 数据实例 | 资源低谷期 | 资源高峰期 | 灵活性 |
|---|---|---|---|---|
| 1 | 普通实例 | 在低谷期浪费的资源较多 | 在高峰期资源不足，业务受损 | 比较固定的资源 |
| 2 | Serverless实例 | 在低谷期可以动态弹性释放不需要的资源，从而减少了资源浪费 | 在高峰期也能完全满足业务需求，保证业务不受损，提高了系统的稳定性 | 动态弹性伸缩能力 |
总结：由于Serverless实例的规格会随业务需求量随时调整，总体浪费的资源很少，提升了资源利用率，降低了资源使用量。
4. TDSQL-C MySQL Serverless的优势：
| Item | 优势项 | 描述 |
|---|---|---|
| 1 | 更低的成本 | (1). 对于创业初期的企业，MySQL Serverless不依赖其它的基础设施和相关服务。 (2). 即买即用并可以提供稳定和高效的数据存取服务。 (3). 使用期间只需要为占用的资源按使用量付费。 |
| 2 | 更大的存储空间 | (1). 存储空间最大可高达32 TB。 (2). 根据实例数据量自动扩展，可以有效避免集群存储资源不足对业务造成影响。 |
| 3 | 计算资源自动弹性扩缩容 | (1). 用户读取和写入需要的计算资源可弹性伸缩。 (2). 不需要手动扩缩容，极大减少了运维成本和系统风险。 |
| 4 | 全面托管和免运维 | (1). 版本升级、系统部署、扩缩容、报警处理等底层服务不需要关心。 (2). 用户无感知，业务无影响，服务持续可用，真正免运维。 |
5. 适用场景：
- 开发、测试环境等低频数据库使用场景
- 中小企业建站服务等SaaS应用场景
- 个人开发者用户
- 学校教学、学生实验等教育场景
- 物联网（IoT）、边缘计算等不确定负载场景
- 全托管或希望完全免运维的用户
- 业务有波动或不可预测的用户
- 具有间歇性定时任务的业务场景
五、TDSQL-C Serverless数据库的三大特性：
Serverless 是腾讯自研云原生数据库 TDSQL-C MySQL 版的无服务器架构版，自动扩缩容，仅按照实际使用量计费，不用不计费，轻松应对业务数据量动态变化和持续增长。
1. 自动启停，不使用无计费：
Serverless 服务支持自定义实例自动暂停时间，无连接时实例会自动暂停。当有任务连接接入时，实例会秒级无间断自动唤醒。
2. 按使用量计费：
可调整 CCU 弹性扩缩容的范围，Serverless 集群会在该范围内根据实际业务压力自动增加或减少 CCU。
3. 自动扩缩容：
Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据一定的规则触发自动扩缩容策略。
六、自动启停，不使用无计费：
1. 需求描述：
| 1. 需求背景： |
|---|
| 可根据业务需要，自助开启或关闭自动暂停设置 |
| 2. 实现思路： |
|---|
| 1. 自动启停的逻辑比较简单，默认只要1小时（用户可配）内监测到没有访问就回收掉计算节点，访问回来就把节点重新拉起。 2. 也可以在控制台，指定数据库实例进行手动暂停操作。 |
2. 测试方案：
date +"%T.%N" && mysql -h gz-cynosdbmysql-grp-9eujfhd.sql.tencentcdb.com -P 27304 -u root -pDb123. -Nse "show databases" && date +"%T.%N"3. 测试结果分析：
Linux的date命令可以用来显示或设定系统的日期与时间，通过获取命令开始前时间，再获取命令开始后时间，可以得到这条命令一共花费的时间值。
命令参数：
%T 时间(含时分秒，小时以24小时制来表示)。
%N 在显示时，插入新的一行。
先将TDSQL-C MySQL如上述两种方法停掉，使用MySQL自带的“show databases”命令查看所有的数据库，因为默认的命令，也不涉及到什么慢查询，只能算空负载运行。可以看到执行的时间差，可以是秒级连接。
从TDSQL-C MySQL的实时监控报表也可以看出，在14：15之前的时间段是暂停的状态，在15：00左右，有连接访问，马上就秒级启动服务器，充分的说明了当没有数据库请求时，监控服务会触发计算资源的回收。当用户再次访问时，接入层则会唤醒集群，再次提供访问。
4. 原理说明：
TDSQL-C Serverless冷启动秒级内就能完成，怎么做到能贴近云函数的启动时间呢？
当有连接访问时，系统会秒级自动启动处于暂停状态的数据库，用户不需设置重连机制。
- TDSQL-C MySQL 版的接入层增加了一个恢复感知器（简称 perceptron）的模块来实现请求转发，perceptron 在和客户端握手之后，不会使用户端到集群的连接断连。恢复集群后，与 TDSQL-C MySQL 版握手，后续转发四层报文。
- 整体流程设计采用了两个挑战随机数进行鉴权，以实现中继模块 perceptron 不存储用户名密码的情况下也可以完成用户名密码验证，保证了用户密码的安全性，也不会引入存储密码不一致的问题。
- 当集群处于暂停状态时，仅保留 perceptron 的路由
- 当集群恢复后时，系统同时保留 perceptron 的路由和 TDSQL-C 的路由，并设置 perceptron 的路由权重为 0，以实现新增连接直连到 TDSQL-C，同时存量与perceptron 已经建连的连接依然能够通讯。
七、按使用量计费：
1. TDSQL-C MySQL 版 Serverless 服务的计费说明：
| 1. 计费模式 |
|---|
| (1). Serverless 服务的计算和存储独立计费。 (2). 计算按 CCU 个数计费，存储按使用量 GB 计费，计费系统按秒计费，按小时结算。 |
| 2. 计费公式 |
|---|
| Serverless 总费用 = 计算节点费用 + 存储空间费用 = Serverless 算力价格 × CCU 量 + 存储空间价格 × 存储空间 |
定义了一个算力单元CCU（TDSQL-C Compute Unit）=max {CPU, MEM/2, 最小规格}。
- MEM/2的含义是，由于定义的规格CPU/内存比都是1/2，内存除以2相当于把内存换算成CPU。
- 整体还是以CPU决定整个算力。
- 通过计算每个小时CCU平均值给用户计费。
2. 创建一张订单表：
创建一张订单表，用于方便写SQL语句进行压测，如下我们会进行一下insert写的场景压测，分析一下，TDSQL-C MySQL怎么样实现使用量计费。
CREATE TABLE `orders` (`order_id` bigint(20) NOT NULL COMMENT '订单编号',`customer_id` bigint(10) NOT NULL COMMENT '下单用户编号',`product_id` bigint(15) NOT NULL COMMENT '产品编号',`product_name` varchar(30) NOT NULL COMMENT '产品名称',`product_price` decimal(10,2) NOT NULL COMMENT '产品价格',`quantity` int(11) NOT NULL COMMENT '产品数量',`total_price` decimal(10,2) NOT NULL COMMENT '总价格',`order_time` datetime NOT NULL COMMENT '下单时间',`delivery_time` datetime NOT NULL COMMENT '发货时间',`status` int(1) NOT NULL DEFAULT '1' COMMENT '订单状态 1：已完成 0：未完成',`address` varchar(100) NOT NULL COMMENT '家庭住址',`phone` bigint(11) NOT NULL COMMENT '联系电话',PRIMARY KEY (`order_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单信息表';创建表执行SQL成功。
3. 使用腾讯云的“云压测”进行测试：
云压测（Performance Testing Service, PTS）是一款分布式性能测试服务，可模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性。支持按需发起压测任务，提供百万并发多地域流量发起能力。提供流量录制、场景编排、流量定制、高级脚本定制等功能，可快速根据业务模型定义压测场景，真实还原应用大规模业务访问场景，帮助用户提前识别应用性能问题。
创建一个压测的案例场景，为了更好的说明按使用量来计费，我们选择了递增压测的方案，模拟一下根据不同的业务量，产生不同的负载，Serverless 集群会在该范围内根据实际业务压力自动增加或减少 CCU，根据不同的算力CCU产生不同的费用。
压测场景说明：
一共压测2000VUM，最大的并发数是10VUs，为了还原生产的场景，按阶段性递增进行压测，一共压测4分钟，在1分钟内分3次过去逐渐增加并发数，由3.33VUs到6.66VUs，再到10VUs，演示流量逐渐慢慢增长，看一下CCU的弹性自动扩容能力。
以下是这次递增压测的结果报表，一共是576809个请求（接近6w个请求），没有一个网络请求失败的，平均的响应时间是在3.75ms，最高的并发数是在10VUs，下面的折线图也是分为3次有规律的进行递增。
举例说明，我们设置了算力配置为：选择最小最大规格为0.25核-1核：
从图中可以看到，递增压测分为3波：
- 第一波初期的CCU在0.25左右，就会按0.25算力来进行计费
- 第二波的CCU在0.5左右，就会按0.25算力来进行计费
- 第三波业务高峰过来，CCU逐渐升高到0.691左右，就会按照0.69来进行计费，能够很好的应对业务负载。
- 在压测结束后，CCU逐渐从0.5降到0.25，再到0，不使用就不计费
下图可以看到我们在压测产生的同时，CCU的费用也提高了，可以很方便的进行自动扩缩容，访问量上来时自动扩容，降低时自动缩容，按照实际使用的资源付费，不使用不计费，如果没有访问，就不收费。
以下为CPU、内存的性能数据参考，都是正比的增长趋势，所以，上面讲到的CCU的计费方式，跟CPU和内存是有关系的。
八、自动扩缩容：
目标是做到秒级的扩缩容，并且期间对用户是平滑的，无感知的。
以上图为例子，用户在购买时选择最小规格为1核2G，最大规格为2核4G。
1. 如果是传统的MySQL数据库实例：
初始为1核2G，当业务访问过来，把CPU用满了时，用户需要手动去修改规则，修改后需要重启后才能生效。
2. 如果是TDSQL-C MySQL Serverless数据库实例：
- 初始就给用户提供最大CPU规格，内存则从最小规格开始，假设用户使用的CPU超过1核，并持续一段时间，将把内存从2G扩到4G。
- TDSQL-C Serverless的CPU资源不会受限，可以在设置的最大规格内任意使用。优点是用户性能不受限，引入的缺点是可能整机出现满负载。
- 由于TDSQL-C采用存算分离架构，一旦监控到整机资源超过阈值，就进行快速迁移。迁移其实就是在另外一台相对空闲的机器重新拉起实例，秒级完成。在资源负载上可以精准控制。
3. 创建压测测试场景（使用80VUs）：
这里也是采用子递增压测的方式，但是之次使用最大的并发数为80VUs，在1分钟内全部压测完，然后，在前30s使用40VUs，后面30s直接使用80VUS。
4. 压测结果分析：
这里也是模拟一下，应对于突发急剧增加的流量，TDSQL-C MySQL是如何进行扩容的。
- 第一区间是比如正常的业务流量，如下单购物，使用了并发40VUs，最大使用的算力差不多是0.8左右
- 第二区间是突然遇到双11活动，业务的访问量马上急剧增加，这时候，TDSQL-C MySQL可以自动扩容到CCU接近4左右，可以完全满足业务突增的情况
- 第三区间表示活动结束了，对应的业务访问量就降下来了，可以看到CCU也可以弹性的回收缩回到0.8左右
- 第四区间在没有任何访问量的时候，监控服务会触发计算资源的回收，此时，CCU降低到0，没有使用，就可以不收费
从上图，我们可以得出一个结论：
- 秒级的扩缩容，期间对用户是平滑的，无感知
- Serverless 服务支持按实际计算和存储资源使用量收取费用，不用不付费
由于压测的并发数比较大，也可以看到TDSQL-C MySQL有一些诊断提示，我们也可以根据一些警告进行一些系统的优化，以对应业务的变化。
九、秒级扩容背后的架构原理：
1. 主流公司的现有架构：
很多公司目前的主流架构是采用单体冗余架构（一主多从），这种架构在扩展性存在很大的问题。
- 实例的升降级和读扩展，都需要通过数据搬迁来实现
- 随着数据量不断的增长，迁移耗时越来越长
2. 存算分离架构：
为了解决一主多从架构在扩展性这方面的问题，大多数采用的方案是采用存算分离架构。
- 一类是ShareNothing架构，计算和存储均支持水平扩展，扩展能力非常强。但是最大的问题是SQL兼容性，需要不断的持续构建和完善自己的生态。
- 另一类是ShareStorage架构，共享存储架构并没有改变查询引擎和ACI这些基础特性，可以做到100%的兼容性。
腾讯云优先选择了基于共享存储架构的数据库产品TDSQL-C提供Serverless服务。
TDSQL-C是腾讯云基于共享存储架构的云原生数据库，由于ToB业务对稳定性的要求很高，复用了云上比较成熟的组件。
- 在计算层使用腾讯维护的MySQL内核分支-TXSQL，复用它的bugfix和新特性
- 在存储层使用腾讯内部的云硬盘CBS，把CBS的核心存储和硬盘逻辑进行剖离，打造了统一存储平台HiSTOR
作为存储底座，加上云硬盘CBS、云分布式文件系统CFS等多款云上的产品，提供副本同步、故障自动迁移、数据校验等一系列完善的数据安全保障能力，这正是TDSQL-C MySQL Serverless产品能够稳定运行数年的重要基石。
十、 总结：
随着云计算的发展，Serverless架构带来的优势，就是用户不用更多的去考虑服务器的相关的运维工作，无需再去考虑规格大小、存储类型、网络带宽的问题，Serverless架构会帮助自动扩缩容、无需服务器运维了、无需备份数据、软件配置等工作。
随着 Serverless 概念的迅速普及，腾讯云数据库TDSQL-C也推出了 Serverless 产品形态，可以为用户提供更低成本、更灵活的云数据库服务，减少了用户维护数据库规格的负担。
通过上面对TDSQL-C Serverless 在自动扩缩容、按使用量计费、不使用不计费3个方面进行学习与探讨，TDSQL-C Serverless在无负载时不产生任何费用，而当业务流量到来时能够秒级自动扩容扛起突发请求，做到按使用量分配计算资源、按使用量进行扣除费用。
对于开发者和企业来说，Serverless 服务是腾讯云自研的新一代云原生关系型数据库 TDSQL-C MySQL 版的无服务器架构版，是全 Serverless 架构的云原生数据库。Serverless 服务支持按实际计算和存储资源使用量收取费用，不用不付费，可以为企业很好的进行降本增效。