什么？只为业务高峰付费，低峰不付费，还有这种好事？

7月中旬，腾讯云7*24h售后支持群收到来自X-Girl（化名）客户的消息，客户直呼咱家数据库帮大忙了，想要亲自感谢腾讯云MySQL团队。

诶？怎么回事呢？

关于X-Girl

X-Girl是一家线上线下同时运营的女装店，既从厂家拿货转售给各大渠道商，又同时经营自家店铺。为方便自家店铺的经营以及渠道商的下单，订单交易从原来的微信沟通转移至网店、小程序等。X-Girl公司拥有一名懂技术的人员，但是也不太熟悉数据库，因此早在建站初期就加入了腾讯云数据库7*24h售后支持群，平时运维管理也很轻松。

原来，在7月初X-Girl客户家的一款小黑裙突然爆红，网店、小程序等访问量飙升，但这次的爆红跟之前的爆红可不一样，系统岁月静好，仿佛无事发生。之前突然出现爆款产品时会页面卡顿、访问崩溃，本来都做好了和渠道商挨个解释的准备，这次居然都没有？这成功引发了DBA的好奇心，经过复盘，破案了。

原来半个月前DBA看到控制台上更新了“CPU弹性扩容”的新功能，开启不收费，触发之后才开始收费，想到曾经CPU利用率打到90%的刺激经历，于是DBA决定试试，万一呢？命运的齿轮开始转动……

咱家的CPU弹性扩容功能是6月28日上线的，X-Girl因为长期使用控制台关注到了这个更新，第一时间就买定离手。巧的是，7月初小黑裙频登热搜，原厂同款小黑裙早已断货，X-Girl的同类型小黑裙因价格实惠被渠道商和散客疯抢。CPU弹性扩容就这样派上了大用场。

来吧，有了CPU弹性扩容，再“爆”都不带怕的！

那么CPU弹性扩容究竟是个啥？本期就让小编带您走进CPU的世界。

为什么推出CPU弹性扩容?

总结起来就几句话——“应客户之诉求，防CPU之风险，解升配之困难，降客户之成本”，帮助客户弹得更快更稳的同时，还更便宜。

众所周知，业务存在高峰低谷，多数情况下客户选择一个配置就要持续为其付费，无论高峰无论低谷。“高峰前我们升配真的很难，而且高峰并不好预测，有没有办法实现短时间快速把计算资源升上去呢？还有，低峰期我用不上这么高规格的实例，成本真的很高”，大客户向腾讯云MySQL团队诉苦，并期望能尽快给出解决方案。CPU弹性扩容功能就是这么来的。

CPU弹性扩容功能的必要性其实无需评估也知道，客户害怕CPU被打爆，CPU也容易被打爆，尤其在降本的时代，能用小规格客户就会使用小规格。一旦出现突发流量、死锁、慢查询、高并发等情况，服务就会有不可用的风险。

一旦发现CPU被打爆或者预测流量高峰即将到来，客户的第一反应一定是“赶紧升配”。现网变配时长会受到数据量的影响，导致等待时长不定，同时升配过程中可能会出现闪断情况，影响业务正常运行。

CPU弹性扩容功能的原理非常好理解，当数据库访问量增加或CPU资源占用率上升时，CPU资源弹起来，并在高峰期结束后自动缩回去。那么CPU弹性扩容是怎么帮助客户节省成本的呢？很简单，就是客户只为业务高峰付费，无须为业务低峰期付费。我们一起来算一笔账：

假设客户使用北京地域32C 256G 通用型三节点，每天高峰期合计1h，其余23h为低峰期。我们就按照当天升配的情况，配置升级至48C 488G使用24小时需额外付费（207.4 - 108.8）*  24 = 2366.4元，而使用CPU弹性扩容仅需额外支付32 * 0.81 * 1 =25.92元。也就是说，在该情况下一天节省2340.48元，成本降低98.9%。

怎么弹？

CPU弹性扩容功能基于云环境优势，实现动态分配CPU资源。用户可在控制台上选择是否开启 CPU 弹性扩容功能，根据业务的需求和业务量动态地配置数据库的CPU资源，从而完成弹性扩展，应对高峰压力，确保数据库实例的高性能、高可用性和高稳定性。

CPU弹性扩容功能分为【自动扩容】 与 【手动扩容】两种类型，其中：

自动扩容：用户自行设置扩容阈值和观测周期，默认扩容1倍核数，当实例 CPU 达到阈值超过观测周期时，扩容功能生效。相同地，当实例 CPU 达到缩容阈值超过观测周期时，缩容功能生效，期间无需客户做其他操作。

手动扩容：手动扩容可选择扩容核数，支持1核单位扩容，最高支持1倍核数。当用户开启手动扩容成功时，实例按照扩容后的 CPU 核数运行。当业务无需更多 CPU 资源时，需手动关闭 CPU 弹性扩容，否则收费会持续进行。

用实验数据说话

功能操作简单又效果明显，真的那么好使吗？一起来做个对比实验看看吧！

批量购买3个 北京七区 通用型2C 4G 双节点云数据库 MySQL 实例，分别为：

A 组 ：NO-CPU-Expand，不开启 CPU 弹性扩容功能

B 组 ：AUTO-CPU-Expand，开启 CPU 弹性自动扩容功能，CPU利用率超70% 1min则触发自动扩容，CPU利用率低于30% 5min则触发自动回缩；

C 组 ：MANUAL-CPU-Expand，开启 CPU 弹性手动扩容功能，扩容核数为2核；

Tips：建议提前设置max_prepared_stmt_count 参数为最高值，应对高并发。

sysbench 准备数据，单表10w 数据量，10 张表：

sysbench –-db-driver=mysql –-mysql-host=xxx –-mysql-port=xxxx –-mysql-user=xxx –-mysql-password=‘XXXXXXXXXX’ –-mysql-db=sbtest -–table_size=100000 –-tables=10 –-events=0 –-time=XXX –-threads={X,Y} oltp_read_write prepare

sysbench 运行高并发：

sysbench --db-driver=mysql --mysql-host=xxx --mysql-port=xxxx --mysql-user=xxx --mysql-password=‘XXXXXXXXXX’ --mysql-db=sbtest --table_size=100000 --tables=10 --events=0 --time=XXX  --threads={X,Y} --percentile=95 --report-interval=1 oltp_read_write run

如下图所示，在三组CPU弹性扩容功能的对比实验结果中，我们可以看到：

第一阶段：21:03开启数据注入，NO-CPU-Expand 和 AUTO-CPU-Expand 的CPU利用率打到70%以上，但时长未超过1min。因此，AUTO-CPU-Expand组未触发自动扩容功能；而，MANUAL-CPU-Expand一开启即扩容，已经是4核运行状态，CPU利用率不到50%。

第二阶段：21:07开启高并发测试，NO-CPU-Expand的CPU利用率始终在70%以上，AUTO-CPU-Expand 的CPU利用率在70%以上超过1min时触发了自动扩容，秒级扩容成功，利用率降低至50%以下；MANUAL-CPU-Expand的CPU利用率始终保持在50%以下。

除了CPU利用率有显著变化外，开启弹性扩容功能的实例性能表现同样明显（毕竟多了一倍核），如下图所示，开启弹性扩容功能的TPS、QPS均高于未开启的实例。

注意：测试的性能表现与测试时段、时长、机器等因素有一定的关系，建议多次测试对比结果。

这么好用，贵不贵？

如上文所述，CPU弹性扩容分为自动扩容和手动扩容两种类型，不同类型其收费逻辑是不同的。

自动扩容弹多少计多少，不弹不计费，可以完美实现“无需为低峰付费”这一理念。也就是说即便我们早早的在控制台开启了自动扩容，并不是马上就开始计费的，而是成功触发了扩容条件之后，才开始计费。缩容也是如此，成功缩容后收费停止，客户无需在控制台上点击关闭。

注：为避免出现持续间歇高峰的影响，在自动扩容时存在最短保护时间，为10min。即整个自动扩容过程小于等于10min时，按照10min收费，大于10min时，按照实际使用时间收费。

手动扩容则是开启功能即计费开始，关闭功能即计费结束。所以选择使用手动扩容的客户可要注意咯，一定要记得手动关闭哦。

同样的，我们拿上述实验做个计费说明，如下图所示，我们可以看出：

AUTO-CPU-Expand在21:07时CPU利用率达到70%以上，在21:08时观测时长超过1min，成功触发自动扩容，此时计费开始。缩容观测周期为5min，小于最短保护时间（10min），因此实例在21:18触发自动扩容关闭，此时计费结束。因此，AUTO-CPU-Expand计费周期为21:08--21:18，时长为10min，最终花费0.18元。

MANUAL-CPU-Expand在20:52时手动开启，此时计费开始。功能在21:26手动结束，此时计费结束。整个手动扩容过程时长34.09min，最终花费0.61元。

相信不用比较大家也能很清楚，开启自动扩容一定是个绝佳的降本选择。

都看到这儿了，不试试？

综上，腾讯云 MySQL 推出的CPU弹性扩容功能，支持根据设定的 CPU 平均使用率阈值和观测周期进行自动扩缩容，也可以支持手动扩展当前实例的 CPU 上限，能更好的缓解突发请求带来的性能压力，适配业务高峰流量，保障线上业务稳定性。未来，腾讯云 MySQL还将继续优化该功能的设计，推出独享型实例CPU弹性、自定义扩容时间等功能，完善事件告警策略，给到客户更优体验。如果您想深入了解该功能，欢迎进入腾讯云MySQL产品文档主页，查看CPU弹性扩容的全面攻略。

文章转载自公众号：腾讯云数据库