亮点回顾：拒绝高峰低谷都为高规格付费，CPU弹性扩容带您节省资源成本原创

各位线上的朋友们大家好，欢迎参加腾讯云企业创新在线学堂系列课程，我是本次会议的主持人Lisa。腾讯云企业创新在线学堂是围绕企业业务需求，聚焦在数据管理、AI安全、办公协同等8大数字化需求场景推出的系列课程，携手腾讯云创新无限可能，共同开启企业成长新篇章。腾讯数据库MYSQL是一种基于云计算技术的关系型数据库。它能够提供高可用、高性能、高安全的数据库服务，为中小企业的客户啊提供可靠的数据解决方案。那相较于传统的本地数据库，腾讯云数据库my circle的优势在于可以帮助企业降低运维成本，提高数据安全性和可靠性，提升业务效率和竞争力。CPU弹性扩容功能，基于云环境的优势，实现动态分配CPU资源。当数据库访问量增加或者CPU资源占用率上升时，能够自动添加更多的CPU资源，并在高峰期结束后自动缩减，支持用户自主选择是否开启CPU弹性扩容功能，根据业务需求动态配置，从而实现弹性扩展，应对高峰压力，确保数据库实力，确保数据库实力的高性能、高可用和高稳定。腾讯云数据库MYSQL最新推出的集群版，解决了现有形态横向扩容受限、客户扩增无慢等问题，为企业提供快照恢复、急速变配、暂停实力备机、指读等能力，在高稳定的服务上啊再添灵活性。

好了，那首先呢，就让我们有请，今天的第一位分享嘉宾是来自腾讯云数据库高级解决方案架构师李邦国，李老师多年深耕在数据库行业，具有丰富的数据库运维以及售前经验，那目前主要负责华东地区腾讯云数据库的售前工作。今天李老师的分享主题是直接客户现场C弹性扩容应用与实践，有请。

老师们下午好，然后我是来自腾讯云的数据库解决方案架构师，我叫李邦国，嗯，我这边目前主要负责华东地区，嗯，我们的数据库产品的售前以及继续技技术咨询等工作，嗯，接下来呢，将由我嗯给大家介绍一下CPU弹性扩容的应用与实践，然后嗯，总片呢，我会给大家分享一下，就是CPU弹性扩容它这个功能是是是一个什么样的功能，然后它的特性以及怎么去用。然后我还会介绍一下，就是说我们嗯，CPU弹性扩容，它解决了哪些问题，以及客户的对应的一些场景，嗯。首先啊，我们先看一下，就是其实我们数据库呃，经常会碰到就是CPU被打爆的这么一个问题，那这个问题其实也是我们基本上是我们非常痛的一个痛点问题，嗯，打的原因呢，其实有很多种。

比如说我突发流量，导致我的连接数过多，那这个时候呢，其实我本身建连以及我的连接数的占用，其实都会占用很多的CPU资源，然后再就是我的数据库缓存命中率低，缓存率缓存命中率低呢，其实就意味着我会触发大量的物理读写，也就是大量的读此读写磁盘的操作，那这个时候呢，也会占用大量CPU资源，所以时效呢，也是类似的这么一个场景啊，所以时效呢，其是可以简单理解为就是说大部分场景化场景下，其实都是嗯出就都是会触发我们的就是全表扫描嘛，全标扫描很多时候都是也会触发，就是大量的物理读写。然后除此之外呢，还有可能就是当我们数据库有各种的所谓的占用以及所冲突的时候，那这个时候CPU会占用，会占用资源呢，会大幅的增加，比如说数据库搜索，然后再就是如果说我们有一些分析的场景啊，比如说各种的多表的join以及我的数据库，嗯，比如说我查询的类似于group啊啊等这样有大量的这种操作，那其实这个CPU占用率也会非常的高。

当然还有非常直观的就是，如果我说我现在有大量的并发线程过来了，那肯定会占用大量的CPU嘛，因为本身线程就会占用，而且嗯，并发线程之间有可能有冲突，然后也是也是会有这种锁的冲突以及占用，嗯，除此之外呢，如果说我们现在的集群本身可能就。就已经要用这么当前这么多的CPU了，但是可能我就是我如果说我的硬件配置不足，那也可能就直接会被打爆嘛。这是一个对。所以说就是像刚刚那些解决像刚刚些问题，其实我们基本上会都会有对应的解决方案以及止损方案嘛，但是比如说嗯，我可以去上传一个限流，或者说我优化circle等等，但是最直接的方案呢，还是说我扩容CPU，因为我CPU我的资源量上去了以后，那其实我能承载更多的这么一个对应的这种并发请求，或者说我的病，我的慢查询，呃，就是说我的嗯这种查询类的分分析这种。

那具体呃，如果是我直接扩容的话，那我我是要怎么去做呢？嗯，像我们现在目前的流程，我们可以看到基本上就是分这414步，第一个呢，就是我们去发现，就是比如说我们现在收到了CPU被打爆的告警，那去发现它，然后第二呢，就是当我们发现了以后，那我们去控制台去申请分配，这个过程其实也是都是手动的，对然后申请了以后呢，我们就在等待他的升配中。当他升配完成了以后，那我们去观察是否有恢复，当然说就是如果说我们去做CPU，就是我们的升配不并不一定保证就是说一定能够去把业务一定恢复到，毕竟说嗯，导致CPU这种，呃，就是我们报的原因呢，其实还是有很多的嘛，但是至少说我去双配能够提供一个最直观最直接的一个。嗯，止损以及解决方案，嗯，当我们最后就是业务恢复了以后呢，然后我们再去，嗯控制台，然后申请降配。

这个过程我们可以看到，其实它是有一些就是不足之处的，就是首先比如说我的预期时间不定，就其实我们升配呢，其实是有两种方式，就是比如说极速，极速的升配，以及普通的升配，如果说我升配的时候，那我当前的嗯速主机的就是资源，比如CPU，内存资源足够，那其实我是可以直接把这个资源过来的，那这个配的这个配时间会非常的快。嗯，但是呢，如果说我现在复主机的资源就是没有那么充足的话，那其实就会涉及到底层的数据迁移以及数据切换，那数据切换数据迁移呢，其实就受我们的数据量影响了嘛，那这个时间就不能保证了，有可能这个时间会比较长，那如果说时间比较长的话，那我业务想通过这个来去做快速止损的话，那其实这个就有可能达不到我们的预期。嗯，然后再就是呃，数据库的切换，数据库的切换呢，其实就会存在就是闪断的风险，闪断的风险就是说呃，这个时候呢，可能会影响业务，当然说如果说我们是有应用的，有重机制，并且都是一些短平块的请求，可能是对业务影响不大。

然后再就是除此之外呢，就是还是刚刚说的整个流程其实都需要大量的人工介入，所以说就需要保证我们每就是我们行动比较快速嘛，就是说快速的进行响应，快速的去进行操作，嗯，然后后续，但是呢，也后续的工作也会比较多，我还是要需要人工的去进行，再去保持这么一个观察，然后再去给他这样配。那为了解决这些就是不足之处吧，所以我们推出了嗯，CPU弹性扩容这么一个功能啊，这个功能其实有几几大特点，第一个呢，就是当我的CPU，当我的数据库访问量增加，或者说CPU资源占用量上升的时候，可以自动的增加更多的CPU资源，嗯。

就是主打一个快速响应吧，嗯，然后可以去更快的去进行，呃，扩容我的资源，然后更快的进行止损，并且呢，会在我们的高峰期结束后，然后去进行的进行缩减，嗯，第二个特点就是说我可以在我的控制台呢去进行就是自主的选择，就是就是我们是有扩容呢，其实是有两种能力，一是包括自动扩容以及手动扩容，然后我们也可以选择，就是要扩容的CPU的能量。嗯，就是按区域来进行扩容分配，第三个点呢，就是是嗯，我们可以更大的降低成本，就是我无需再为嗯低峰付费，就是我们正常情况下的业务呢，其实都包括高峰和低峰，但是传统的马S口的做法呢，其实都是我们要至少要满足高峰期这么一个业务需求的这么一个配置量，然后在低峰期呢，其实根本不需要这么多的量，但是我还是需要保持这么一个容量，因为如果我不保持的话呢，可能在高峰期，如果说我再扩容可能就来不及了。

那但是这样呢，其实会给我们造成大量的就是成本的这么一个损耗，那下面其实是有一个计算结果啊，就是说。像我们就是如果是正常情况下，24小时我进行升配，那可以看到这一天的这么一个花费呢，可能是在2300多块钱。但是如果是用嗯自动的就是CPU才能扩容，如果说高峰期只有一个小时的话，那其实我只需要就是为这一个小时的高峰期来付费，那可以看下来就是32岁的情况下，只需要26块钱左右，其实这个这个这个成本对比下来其实节省了非常多，就是一天的成本最高能够降低98.9。刚刚说了这么多，那CPU弹性扩容，嗯，到具体是什么，这个其实前面就是介绍这么多，老师们应该也有一定的了解，那我再简单的再介绍一下，就是CPU弹性扩容呢，指的就是基于语音环境，通过动态分配CPU资源，然后可实现就是CPU资源的手动以及自动调整和弹性的扩展，主打的就是一个快速响应以及变更嘛。

嗯，那具体它是怎么谈的呢？就是我们刚刚都说了，它是会自动的谈，嗯，也可以按序谈，那它具体是怎么谈的呢？嗯，所以呃，我们的CPU弹性扩容就是主要分为自动扩容以及手动扩容两种类型，首先我们先来说一下自动扩容，嗯，自动扩容呢，其实就是说我们会有一个就是说各种阈值以及观察周期。就是如果说我的扩容就是我的阈值，比如说我们设置了70%，就是CPU使用率啊70%，然后它的观察周期呢，可能是一分钟，就是说如果说CPU百分之超过了70%，并且持续了一分钟，那我们就会触发我的呃自动扩容操作，那自动扩容操作呢，其实他会他做的操作呢，就会检查我本地的资源是否充足，然后呢，会把我的空闲CPU分配到我的实力上。

嗯，这个时候来来满足我们就是CPUCPU资源的这么一个需求，当我就是当我就是我CPU就是后续下降了嘛，就是是就是恢复恢复了，或者说低峰期，高峰期结束了，那下降到就是一个更加合理的这么一个CPU的占用率的这么一个值的时候，当然这个也是我们自己配置的啊，就是那我会自动的把CPU就会再降下去就是。之后就不需要为我们的这个增加CPU的这么一个，呃嗯资源，然后再去再去付费了。那手动扩容呢，就然后手动扩容，手动扩容呢，其实顾名思义，其实就是要我们手动去操作，就是我们手动操作呢，就相当于是我。去操作，然后我去指定，就是我要呃增加的就是CPU的核数，然后确认了以后呢，就是会立即，但是会立即发起啊，这里需要就是可能需要关注一下，就是它是会立即发起，立即发起然后去呃检测就是是否有资源，然后进行扩容，然后它的计费呢，也是说当我开启了以后，就是立即开始计费，然后CPU的资源扩容呢，也是立即开始进行扩容，对只只有当我们就是手动把它关掉的时候呢，它才会停止计费，以及把这个CPU的核数呢给降下来。

这里其实就是给大家介绍一下呢，就是呃，弹性扩容它的具体操作，嗯，就是像我们一般就是我们可以直接登录到，就是我们的控制台的实例详情页，这里其实有一个CPU弹性扩容的功能，在这里可以看到有一个CP弹性扩容功能，然后我们直接点击开启，开启呢，其实是会触发出现一个窗口啊，这里会就会让我们选择是自动扩容还是手动扩容，然后自动扩容我们这里看可以看到，就像我们刚刚说的，有一个阈值，一个观察周期，包括扩容和缩容这里都有啊，就我根据我们的业务实际业务情况来去配置就好。

然后然后这里就是说它扩容的核数具体有多大呢？其实我们，嗯，就是当前版本，其实是根据就是我现在的配置规格来去做的，就比如说我是2C4G，那我最大能够扩容到就是4C，那如果是8C16G，那我最多是能扩容到16C，也就是8×2，就是我现在的核数乘以2。嗯，当然可能我们后续新的版本会有变化，我们后面的就是老师会也会给大家去进行介绍啊。然后第二个点呢，就是计费，计费呢，其实就是说我们现在是按容量来计费，然后按分钟计费，并且每小时来扣费一次，嗯，并且我们是有一个最大保最短的保护时间啊，也就是10分钟，就是说呃，如果说我现在触发的就是自动扩容，那我会至少我会先扩容10分钟，保持10分钟就是来避免就是出现这种嗯，持续的间歇高峰的这种影响。嗯。那手动扩容呢，它的这个操作的位置是完全一样的，就是这里可能点击的窗口，就是窗口内呢，我点我们点击手动扩容，手动扩容这里让我们选的是是额外增加的CPU核数，它的上限呢，其实也是我们当前配置CPU核数的两倍，比如现在我们是两倍4g这么一个规格，那呃，我们最大呢，可以扩容就是增加2C，当然我们也可以手动指定EC，对这这个就是手动扩容率，它就有灵活的地方，然后并且呢，我们每增加一核的CPU。

然后我们还会增加1000的IPS，也就是说我们CPU弹性扩容呢，其实不只是增加我们的CPU资源量，而且我们还会增加我们的IO能力，这个是不管是自动扩容还是手动容都会增加的，就是一样的，然后需要还也是需要注意的一个点呢，就是还是我刚刚就是说过的，就是说我们开启就会计费，就跟自动扩容不一样，自动扩容是当需要的时候才会计费，嗯，然后关闭的时候呢，才会停止计费，嗯。

那如何我们刚刚也说了，就是怎么去开启，以及它怎么去谈，那我们怎么去确定它是否生效呢？这里其实就是就有，呃，就就有几种方法，首先最直观的也是就是我们就直接查看我们的实例详情页，那我们可以就是在这里CPU弹性扩容这里可以看到，比如说我现在是自动扩容，对吧，然后自动扩容的阈值是70%。手动扩容呢，这里会有手动扩容，以及我们额外增加的合数，对这里还是很清晰的能够看到，嗯，然后除此之外呢，我们也可以在我们的任务列表页，然后来看我们就是操作的这么一个任务，然后它它的状态，那这里其实就已经执行成功了嘛，那这就是正常的。嗯，除此之外，那这个其实前面介绍的呢，其实都还是需要我们手动的去查看的，那这个这个可能有的时候并没有那么及时。那就是我们还有一个能力呢，就是可以通过事件告警，然后去自动的去进行通知，嗯，事件告警呢，其实是我们自动去配配置的，然后是手动去开启，然后嗯，可以配置我们的联系方，就是通知的方式啊，以及对应的通知人，嗯对应的状态呢，就是就这下一就是我们右边看到这6种状态，然后当我触发这6种状态的时候呢，都会以事件通知的方式来去通知给大家。

嗯。那我扩容了以后呢，其实我我这个资源怎么才再去把它弹回去，嗯，像自动扩容呢，其实是他当我的CPU资源用量就是降下来了以后，那它是会自动缩下缩回来的，缩回来了以后，其实这个时候就刚刚说的它就不会计费了，嗯，然后手动扩容呢，就是说像刚刚说的手动开启，手动关闭，这都需要手动操作来做。当然还有自动扩容，还有一个操作就是说，如果说嗯，我现在就是想强行关闭呢，那其实强行把它搜回弹回去，那我也可以，呃，就是关闭，就是自动扩容这么一个我们的这个功能，那它也会自动把这个CPU资源呢给降下去。

前面讲讲了这么多，可能就是嗯嗯。相对来说就是有点可能。过去了几分钟吧，可能记忆可能有有点没有那么深刻，那我再我们再通过这么一个就是例子，然后看一下他们有完整的生命周期，具体是怎么去操作去执行的，首先先就是先介绍一下，就是我们的蓝色的这一个曲线呢，就是说没有开启，就是CPU弹性扩容功能的。也就是默认情况下肯定会保持它的规格，比如这就是2C4G嘛，就是我们前面的配置，然后紫色的是开启了自动扩容，然后绿色呢，是开启了手动扩容，然后这里就是在最开始的时候，我们就已经开启了手动扩容的这么一个能力，所以说嗯，这个手动扩容就是我们已经把它扩大了付费就是就是默认情况下，就是我的我现在规格是2C分析，然后我已经扩大了付费了，所以说当我第一个请求过来的时候，我们可以看到手动扩容其实我们的资源利用率只有就是呃，没有扩容资源的这么一个利用率的一半，因为我因为我们的CPU核数已经是它两倍了嘛，所以利资源利用率只有它的一半。

那但是我的自动扩容，为什么这个时候它的利用利用率并没有降下来呢？也就是说它没有自动去扩呢，这里就是前面刚刚我们介绍的，它是有一个周期，就是呃，除了说我虽然已经超过了我的70%，但是可以看到我们的持续时间只有30秒。就是我们设的是1分钟嘛，就是它没有超过1分钟，那这个时候呢，其实我们还没有它触发到我们就是就是我们的观察观测时长，所以这个时候是不会扩的，因为这种可能是监测啊，嗯，可能绝对可能就是我们都，当然这个是还是我们根据我们的业务情况来去配置啊对。然后第二次就是当我的高峰过来的时候呢。其实就就可以看到我的手动扩容还是一直保持在我的嗯，40%多，50%这么一个量，因为因为它的它的容量，它的CPU核数呢，本身已经嗯扩大了4C了嘛，嗯，但是然后我的如果是没有开启所CPU手能扩CPU扩容的呢，你我的这个CU的利用率会一直持续的比较高，其续在80%~90%之间，嗯，然后这个时候我们再看我们的自动扩容，其实这里它就已经有变化了，但是变化呢，就是说我们可以看到，首先就是当前的CPU利用率呢，其实超过了70%，对吧，然后当我的这个观测周期就是已经超过了一分钟，就也就是它超过70%，已经超过了一分钟钟的时候呢，嗯，可以看到这个时候我们的紫色的这么一条线就已经在CPU利用率已经降下来了，就说明我们的CPU已经扩容上去了，对，现在就是已经自动的扩容到了QC，然后来满足了我们的业务需求。

最后呢，然后当业务下去了以后，然后我们就会自动的把它弹回去，嗯。

然后然后通过刚刚的生命周周期的介绍呢，然后我们再以这个图，以这个例子为例，然后我们再顺便的介绍一下我们的计费规则，然后让大家就是更直观的看到它就是怎么去计费的，然后它的价格具体是怎么样。嗯，首先我们可以先我们先看一下手动扩容，手动扩容这个比较直接啊，就是从最开始就是开启到最后关闭，那这个呃，计费的时段一共是四十三14:09钟啊，那所以说它的它的成本呢，其实就可以看到，就是说我们是单核的费用乘以CP增加的CPU合数，也就是下面这里有啊，就是0.54×4.2对吧，然后再乘以我的扩容时长，我们是分钟级嘛，分钟集嘛，也就是34.09，然后除以60，然后最后得到一个结果是6毛一，也就这一段时间的。扩容，然后花费一共是六毛，六毛一对，然后再看我们的自动扩容，自动扩容我们可以看到，就是说我们是在这个这个红线，可以看到这个红线。

嗯。这个红线呢，然后就是，呃，我们扩容的时间呢，可以看到只有4分钟，但是可以看到我们下面的这个计费规则呢，其实是按10分钟来算的，这个就是我们最开始提到的最短保护时间，就是我们扩容了以后，虽然四分钟这个高峰期过去了，然后我们使用率降下来了，但是其实在这10分钟之内，我们的CPU是一直是处于四核的状态，也就是属于两倍的这么一个状态的，来防止就是我们这种高峰期间歇这种影响嘛，对，所以说我们的计费呢，也是按最短的就是10分钟来计的，然后它的总的价格呢，是一毛八。可以看到这个这个这个开启了我们的功能以后，其实我们这个成本还是非常的低的，嗯。对介绍了这么多呢，前面介绍了这么多，就是功能特性以及是呃如何使用，那我们可以看一下就是客户呃，他碰见的一些常见问题，以及场景是什么样子的。

然后常见的问题，其实这里比较多啊，我就单独拿出来，就是右下角这一个，我们可以看一下，就是这个是可能嗯。更容易去碰到的一些就是生运行过程中可能碰到一些问题，就是说当我开启了，就是弹性扩容后发生了ha替换怎么办？嗯，这个时候呢，其实呃，如果说我们是双节点或者说单节点的这么一个集群，嗯，这个时候如如果说我扩容的资源啊，扩容CPU资源，比如说已经从2分，然后谈到了4C，那这个时候我们谈的是主备都会去进行谈的。嗯，都会弹上去，所以说当我发生ha切换的时候，切换到备库的时候呢，其实我的那个CPU资源在备库的CPU资源也已经弹上去了，这个是完全能够满足我们的，呃，就是也也能够就是跟主库的这个配置是保持一致。

然后但是需要注意的一个点呢，就是说我的只读实力呢，和我的单位实力是需要单独开启的，就是说当如果说我我的双节点，我的主备呢，可能扩容到了QC，那这个时候如果只读节点没有开启，那他就不会去变着扩，或者说我的主读节点呢开启了，但是呢，它的呃资源利用率没有那么高，那他也不会自动弹上去，对。这个是需要注意一下的。然后但是然后CPU弹性扩容呢，其实它呃呃，它的场景是会非常广泛的，其实相对来说它的场景其实还是呃就就是就是比较比较就比较统一，但是但是对，但是可但是每一个行业呢，其实基本上都是有对应的场景以及解决方案。然后比如说电商，电商啊，新零售行业，像他们直播抢购以及双11大型活动，呃，其实都会触发，就是大病大并发，大量并发请求嘛，对吧，其实这个时候CPU扩容差距其实可以很大的缓解这一块的资源使用率，然后再就是游戏行业，游戏的上线啊，游戏的高峰期啊，以及出行行业的租车打车车企以及通用萨aras行业等等，他们的高峰期的这种这种请求呢，其实都可以通过CPU弹性扩容的能力，然后去扩容我的CPU资源，然后保证他们的业务的稳定性。

嗯，然后然后。对，所以总结来说呢，其实主要的场景，其实呃归纳起来其实主要有几个点，第一个呢，就是说我们可以解决高峰期，嗯就是呃时间就是我们CPU资源的需求，并且可以自动的把它弹上去进行弹缩，然后降低的人力降，降低人力成本，以及提高我们的稳定性，然后第2个就是可能我们周期性的这种峰值的业务场景，比如说报表分析可能会占用非常高的CPU资源，对吧。啊，还有就是呢，我们测试环境的这种低频的常用场景，嗯，可能我的请求。很容易就会，因为我测试的时候可能很容易就会请求突然飙高嘛，对吧，但是测试环境我们又不可能给他预留很多的这么一个资源，嗯，除此之外呢，还有就是成感成成本敏感型的这种业务场景，嗯，就是会根据我们的业务负载啊自动扩容。

嗯，非扩容，非扩容期间呢，它不计费，对就是刚刚说的，就是说我们可以不被积分期来来付费嘛，对吧。那像现在其实我们有很多的客户都已经用了我们的能力，像小红书B站啊，嗯，未来等等其实都有在用，嗯，所以各位老师们就是也可以看一下，就是我们现在的这么一个业务是否有对应，就是这个场景，可能说比如说类似于CPN的这种场景，那是否有适合的，对也可以去尝试，然后去使用一下看看，嗯，我们也是希望就是通过这个能力呢，然后来提高我们的数据库生产的稳定性，然后保证我们的业务正常嘛，对吧？嗯。行，那我我的分享就这么多，感谢感谢大家倾听，嗯，感谢感谢。

嗯，也非常感谢李老师给我们带来的精彩分享，那我们线上如果有疑问的同学也请您在问答区留言，我们的讲师啊会在最后的问答环节为大家答疑解惑。好了，那接下来呢，有请我们今天的第二位分享嘉宾来自腾讯云数据库高级研发工程师樊敏，樊老师专攻云生数据库的开发，那具有多年的数据库管控系统开发经验，主要负责数据库的监控系统弹性扩容等功能的设计和开发，欢迎樊老师给我们带来CPU弹性扩容全新升级，助力业务成本一降再降。主题分享，有请。嗯，哈喽，大家好，我是腾讯云的研发工程师樊敏，然后首先呢，非常感谢这次直播活动，然后非常荣幸能够有机会向大家分享一下我现在正在做的一些事情，然后前面方博老师的分享，从用户和架构师的角度去介绍了一些典型的CPU痛点场景，然后接下来呢，我会从研发的角度来介绍一下我们的产品能力。

然后我今天分享的题目就是CPUCPU弹性扩容，全新升级，助力业务成本一降再降。首先呢，先介绍一下背景。那么就是在我们一个传统云数据库的一个背景下，我通常大家去就是购买一个数据库实例的一个流程，大致应该是这样的，首先去评估自己应用的一个访问压力，去评估需要所需要的计算资源，存储资源等等，然后再根据呃预测出来的容量模型去评估自己需要的数据库资源需求，再根据数据库资源的需求去购买具体相应规格的数据库实例。那么购买实力之后呢，也需要去持续的观察和监控业务的运行情况，去做一些定期的调整，来满足一些不断变化的业务需求。

那么在这种比较传统的一个部署模式的呃背景下呢，就是它整体所有的环节呢，都是以资源为中心去考虑和评估的，然后对用户和不管是对用户还是对我们，就是产品这边的运营，其实也是都带来一些问题。首先就是对用户来说，可能会容易造成资源浪费，然后那么调整规格的过程中，也需要用户去评估资源用量，然后升级过程也也是我们前面说到的可能会比较长，然后有可能会导致闪断等等。那么对于就是研发测和运维侧的话，就是在比如说有一些经典的场景，比如说电商行业的话，在这种活动大促期间，我们会收到大批量的实际规格调整的一些操作。那么这个时候去人工调整的话，会导致就是大量的一些工嗯运维工作，然后同时的话也有可能会造成很多的非标数据，然后对于运维来说，这些数据也是比较难去维护的。

那么对于这个问题来说，其实业界现在已经有比较成熟的解决方案了。嗯，首先就是先说一下这类的一个概念吧，就是。这个也是是是现在应用比较多的一种一种技术方案，然后service主要就是由FA function ASA service和second as service这两种构成的，那么简单理解的话，这里其实就是主要是两个能力，一个是为开发人员提供可以快速构建，就是应用和服务的一个能力，然后第二个就是能够就是提升嗯，能够带来资源的一个弹性伸缩的能力，并且可以按量计费，不使用的情况下不计费。那么我们可能重点关注的是它的第二个特性，那么除了service的话，我们还有还有另外一种技术方案的，就是原原生的一个就是技术。

那么在云原生的话，它主要是在云计算的环境中去构建和部署，就是管理现在的一些应用程序的，那么这里主要是在K8S的环境下去。嗯，依托容器和微服务去去实现一些，就是通过底层基础设施去实现一些高度可扩展的一些能力。那么就是这两种技术概念的话，就是在我们腾讯云的话，其实都已经有了对应的产品，比如说service+database贝的话，对应的就是我们的TD circle-C的产品，然后它主要是基于了计算存储分离的一个架构，来更好的实现service的能力，那么云演云，然后关于云原生加database这块的话，我们今年也推出了一个云数据库买SQL的一个新的产品形态。然后这个感兴趣的话，大家也可以去自行体验一下。

然后再回到这个传统云数据库的话题。就是我们也希望能够尽量的去服务用户的一个需求，在传统的这种形态下去适配资源弹性伸缩的能力。那么就是至于为什么要做这个特性，其实就很简单了，就是对于目前的一个现状来说，公有云的实力规模还是非常庞大的，然后会还是会有很多用户更倾向于使用现在的一个形态的数据库实力，但是状态，这个现在的状态呢，在现在和将来应该会持续比较长的一段时间。那么我们在这种传统云数据库的产品形态下，想要实现单个节点的一个资源的纵向的弹性伸缩的能力的话，它最大的一个障碍就是。单个节点上它所有的资源都是一体的，然后同属于同一台物理机，那么弹性资源伸缩的那个资源的上限，其实就是这个机器本身的一个资源上限，然后虽然说是确实是有这个限制存在的，但是对于绝大多数的中小规格实力来说，这个上线其实已经是完全能够满足需求的，那么我们要做的事情就是能够在有限的资源基础上去实现一个CPU弹性伸缩的能力。

然后从而去去减少一些人工操作的压力呀，以及运维压力和用户的使用成本，提升我们机器的资源利用率。然后接下来的话，我会具体的去介绍我们的这个产品特性的一些价格和。和介绍吧。然后这个CPU弹性扩容的能力呢，是云数据库MYSQ在23年7月份推推出的一款能力，然后目前在线网最主要分为就是自动扩容和手动扩容两种类型，然后手动扩容我这边的理解是它更类似于一个临时的CPU规格升级的操作。

嗯，然后这里限制了，就是最高会按照当前规格的一倍来去做扩容设置，设置之后的话是立即生效的，那么自动扩容呢，是根据实力的真实CPU负载，然后去决策，就是是否要发起自动的扩容或者缩容，然后嗯，现现有的版本的话，我们的扩容的观测周期的力度是10分钟级别的。然后在新版本的就是能力中，我们在就是之前就是推出的这个功能，一年的时间里面，我们也收到了很多的一些用户的需求，然后综合了用户提出来这个需求，我们会在今年的8月份上线一个全新版本的CPU弹性能力，然后在新版本的能力中，我们会把扩容做的更加灵活。然后这里主要是就是优化了一自动原来的自动扩容的能力，然后并且在原来手动扩容的能力中的能力基础之上，提出了一个全新的一个自定义扩容的一个概念。

然后后面的话，我会具体的去讲这两种扩容策略。嗯，我先来介绍一下，就是我们在第一期的那个方案中，然后是怎么去实现手动扩容和自动扩容这两种方案的，然后手动扩容的话，主要是需要用户按需去配置，然后它比较适用于这种就是业务高峰期，然后就是提前去配置的一个场景。然后这里的话，其实它是不需要去关，我们是不关注它的CPU资源的一个真实负载的。那么他在那个后端的一个具体的求请求请求流程大致是这样的，就是用户发起请求之后，会首先。

会首先把请求转发到云平台这边，然后在云平台cloud API收到请求之后，再去发起一个主动扩缩容的请求到管我们的管控平台oss。然后管控平台再去真实的就是我们的实例机上去做扩容CPU的操作，然后并且把同时呢，把这些扩容之后的一些原数据同步到监控系统中，然后最后呢，再做计费回调和一些事件告警的一些处理。然后整个流程的话，我们是目前是可以在5秒之内完成的，然后就是在资源就是满足请资源就是满足的条件下，然后这个流程其实是非常快的。然后自动扩容的话就是。首先这里就是先讲就是去年的一个就是自动扩容的一个实现吧，这里主要是嗯，会去自动检测实例的CPU负载，在负载高的时候自动去增加一倍的CPU规格，负载降低的时候CPU自动回缩。

这里的观测周期呢，就是前面说的，它目前是一个分钟级别的一个配置，可以在1分钟到30分钟之内去做选择，然后扩容阈值的话是在七十七十到百分分之90之间去做，是用户自由的去配置。那么我们的一个扩容时间的话，其实就是观测周期加上一个扩容操作的市场，那么具体的扩容操作的话，这里的就是发起呢，其实是在实例机，我们的一个监控采集系统去触发的。嗯，然后这里的话，我们会做一个秒级的一个，嗯，CPU利用率的一个检测，然后这采集，然后这这个呢，就是跟我们现有的一个就是控制台上展示的监控的。嗯，力度会有一些不同，我们这里呢，会会做一个一秒级的一个采集，然后监控目前现有的云平台上的监控展示的力度是5秒级的那个监控展示。

所以这里的话会更数据会更精确一些，然后在实体机上去采集数据，呃，CPU数据，然后观察，当它满足了观测周期内，然后并且到达了扩容阈值之后，就会触发自动的扩缩容请求。然后这个时候我们同样也是把这个请求转发到管控平台oss去做处理的，然后管控平台再去做真实的就是CPU调整的操作，并且同步原数据给监控系统，然后最后呢，还在做那个计费回调和时间告警的通知。那么这个流程周期的话，其实是。操作时长大概会是在就是根据我们在线网的目前的一个统计啊，会是在1.5秒到2秒之间内可以完成，然后那么我们现在整个的一个扩容速度，就是在观测周期再加上1.5~2秒的一个扩容操作时长。

那么在今年就是即将推出的一个新版本中呢，我们对现有的一个自动扩容做了一些优化，首先呢是我们想做，想提升一下就是现有的扩容速度，那么现在做的一个方法就是把缩容扩容的观测周期去做了一个缩小，然后从分钟级别的力度，然后先调整成了秒级别的力度，然后最小呢是可以支持15秒级别的观测时间。嗯，然后这里的话还有一些决策算法的一个修改，主要是在我们在第一期的就是嗯场景下，可能遇到了一些用户反馈的问题，比如说可能他在监控系统上观察到的就是他的CPU使用率可能已经到达了观观测就是扩容阈值，但是实际上可能在后后端的那个实力机，嗯，我们的采集1秒级的A证的采集去。

嗯。去计算CPU使用率的时候，可能还没有触发，然后这里其实是因为我们的算法的话要求会更高一些，就是这里必须要他要保证，就是连续95%的，比如说一分钟的话，一共有60个点，就需要要求60个点里面的95%的点都能满足要求，都能够到达扩容阈值才会发起扩容，那么嗯，我们今年的话是打算调整一下这里的决策算法，就是适当降低一点，就可能会跟用户的观感上更匹配一些。那么然后还有一点优化，就是我们做了一个阶梯式扩容的一个能力，然后就是对于扩容规格的上限呢，会放会会，相对来说会限，就是限制的更小一些，然后同时呢，把弹性扩容的步数调大。

然后我们可以根据这张图片来看一下，就是现有的一个自动扩容能力的话，它是只能够做单次的扩容的，然后它在低负载时候发起了自动扩容之后，有可能用户的CPU使用率就是仍然是非常高的，那这个时候它其实还是受限的一个场景，那么就是在负载降低的时候再去做扩，再去做缩容操作，那这里就是只能支持一次的扩容。然后今年的一个版本的话，我们会做一个阶阶梯式扩张的一个能力，就比如说用户在低负载的时候发起了自动，呃，用户在高负载的之后，然后发起了自动扩容，自动扩容之后发现他的实力负载还是很高，然后这个时候就会再次去做一个扩容来满足他的需求。那么这里就是最大的，其实是我，嗯，只会受到就是最大资源的一个限制，然后对扩容次数我们是没有限制的，然后每次扩容的一个步长，就是当前的实力规格。

然后前面的话就是对于自动扩容的一个介绍，然后对于今年新推出的一个自定义扩容的一个策略的话，这里的话会。主要是会提供一个更加灵活的扩容时间给用户，然后用户可以决定它的生效时间，以及可以支持设置指定时间段内指定时间周期去做扩容，然后我们是重点去保障它的指定时间段内的一个稳定的CPU性能。然后除了在指定时间段内去做手，就是类似于手动扩容的一个操作的话，在就是指定时间段外，用户也可以去结合自动扩容一起使用。然后就可能就可以满足一个业务低峰期，然后当有就是这种突发流量来的时候，可以去做一个自动扩容，然后在业务高峰期的时候，然后通过手动扩容来保证整个高峰期内的CPU性能，就是可以可以得到一个稳定的一个保障。

然后我这里也写写了一下，它适用的场景，可能是这种频繁高峰期，或者说它的高峰期时间窗口比较小的一些场。那么在就是这种自自动扩容和手动扩容的规则切换的一个时间段内，我们就是怎么去保证它是平滑切换呢？其实这里举个例子，就比如说他这里同时发起了，就是在同时发起了自动扩缩容的请求，跟就是一个指定时间段内的手动扩容的一个请求。或者说是他在就是指定时间段即将结束的时间，我会发起一个手动扩容的规格下调跟自动库存容的一个请求，这里假设遇到了冲突的话，其实我们的我们处理的原则的话，会去重点保障这个不指定的目标时间段内保证它的CPU。

性能不下降。那么我们我们会选择在周期开始的时候去优先处理手动扩容的请求。这里就是还有一个点，就是刚刚王国老师也提到了那个，我们会有一个那个，呃，扩容的一个保护的时间。他的现在的话是10秒内就不能连续扩容了，那这里的话手动扩容的话会不受这个限制。然后再就是手动扩容周期结束的时间段的话，为了保证它的根据它的CPU的真实的负载去去做，就是不是说立即把CPU降下来，而是根据它的争取负载可能去做一个根据，再根据自动扩容的观测周期，然后去做一个缩容的一个操作。

然后还有很多用户可能会有一些疑问，说就是遇到了扩容失败的场景之后，应该怎么去处理。然后首先的话，我们在扩容失败后，会立即发一个告警到事件总线这边，然后就是也非常建议用户去配置事件总线，去及时接收告警，然后同同样的话，今年也会新推出一个扩容历史界面的一个查询，然后用户可以直观的去看到。在哪个时间点有扩容成功或者说扩容失败的任务，那么就是相对于是扩容失败操作可能不太能接受的一些场景下的话，我们会更推荐去使用自定义扩容的一个能力。然后去对，就是指定时间段内去做一个重点的CPU的保障。

然后最后的话，我就来总结一下这3种。这三种就是策略，然后自动扩容的话，就是一个持续的就一秒级别的监控，再加上P95决策，然后它比较适用于这种C对CPU资源上限要求一般，然后扩容速度要求一般，然后可以接受小概率的扩容失败的一些场景。那么自动扩容今年即将推出的一个加强版本的话，我们会提升它的，进一步提升它的弹性能力，然后同时也提高它的最大的可用资源上限。那么这种就比较适用于对CPU资源上限要求比较高，然后同同样的话，它的扩容速度要求一般，然后也可以接受小概率的扩容失败的场景。那么自定义最后自定义扩容的话，是相当于是一个自动扩容加手动结合，手动扩容结合的一个，嗯，一个策略，然后就比较适用于对就是对扩容在指定的时间段内就不接受扩容的时间损耗，然后也不容忍扩容失败的一个场景。

然后最后的话，我们就嗯来说一下，就是我们后面可能会做的一些事情，或者说或者说就是对于后面的一些展望吧。嗯，一个是就是对于内存资源的一个弹性伸缩能力，因为内存的话可能跟CPU的还不太一样，它的场景会处理起来会更复杂一点，就是对于我们来说也比较有技术挑战力一些。嗯，然后第二点就是我们现在可能正在做的一个事情，就是通过AI去提前预测去嗯，去预测它的负载，然后做一个提前的一个扩容。然后第三个就是可能在更多的产品架构上去支持一个CPU弹性扩容的能力。

包括独享型，还有三节点的产品形态。嗯，然后这呃，我这边的分享就结束了。嗯，好的，感谢感谢樊老师给我们带来的精彩分享，那我们线上有疑问的同学呢，您也可以在问答区留言，我的讲师会在最后的问答环节为大家答疑解惑，那接下来就让我们有请今天的第三位分享嘉宾，腾讯云数据库高级产品经理程昌明。陈老师是腾讯云数据库MYSQL产品线的负责人，在高可用解决方案、信息安全、系统规划、性能优化、在纳恢复与信息系统整合方面拥有丰富的实践经验，曾经为网络运营商、银行、能源以及政府等行业的关键业务系统提供为升级、项目实施与管理、容灾建设等一单问题的咨询与技术实施服务。好了，那欢迎陈老师给我们带来向征云原生进化集群新架构，助力企业轻松应对高并发的主题分享有请。

啊好的，谢谢主持人，也感谢之前两位老师的分享，然后通过之前两位老师的分享，估计大家也对啊CPU弹性扩容这样一个能力有了非常深入的了解，然后在樊老师分享的时候呢，然后也提到了一个，我们现在也在往啊搜云原生，然后这个方向去啊。前进，然后我们也看一下，再朝着云原生前进的这个方向上，我们怎么来应对啊，高并发的用户请求，那这样一个难题，那除了我们刚才说的CPU弹性这样一个能力以外，那通过云原生的技术，我们怎么去满足？OK, 首先我们先来看一下第一个问题，就是为什么我们需要一个新的架构来去承载呃这样的一个数据库的服务，然后在传统的这样一个架构上的话，我们可以看到基于传统的纯算一体这样一个架构。

它的它带来的优势就是本地磁盘的IO是极低的，它的IO响应时间非常的短，可以提高非常极致的性能。然后本，然后它本地的资源可以做到无损的弹性，像刚才所分享的CPU弹性这样一个能力啊，然后网络架构相对来说它是比较扁平的，然后它在扩展上其实相对来说比较轻松，比如说你想搭建一组几个重，或者说搭一些异地栽被，然后异地的制度凹，然后都是OK的，都都是可行的，但是在纯算一体化的这样架构里面所带来的单个资源瓶颈就会就会比较明显，比如说因为我存算是在一是在一体的，那就会导致我的备份的方式相对来说会受到很大的局限啊，然后现在传统的方式，然后只会用到h backup啊，然后或者一些就是MY自带的一些，比如说嗯。MYMY, 当然后这样的一个啊工具，然后对它进行一个备份，那这样的一个备份时长以及恢复时长是非常的漫长的啊，然后并且由于计算资源和存储资源进行了一个绑定，那我的磁盘的规格也会受到我计算规格的一个限制，它中间是有一个相互绑定的关系，那你的磁盘不能无限制的向上去增长。

啊，并且你的计算资源也会因为不同代次的影响，然后会有。啊会有不同的表现，以及甚至在不同地域有不同的啊表现，然后这样的话会对用户对性能的认知上会产生一定的偏差，就无法得到一个百分百。它的性能的性能上的一个保障，然后并且由于它不支持快速的热迁，然后以及。快速的故障恢复，那它需要一个不可读的备机给他提供可用性的保障，那相当于我需要花两份计算资源以及存储资源的费用，然后来对整个架构的可能性，然后进行一个保障。并且这。

这一整套资源里面有一半的资源是啊，没有办法去帮助你的业务，然后去进行使用的啊。然后它底层的操作系统的内核的更新相对来说也比较的缓慢，因为整体物理机的底层。内核的更新的话啊，相对来说是比较缓慢的，并且它的整个操作会比较重，那不像原生平台里面，然后那么的轻亮，然后只需要简单的一个red，然后可以快速在分钟级的一个影响下，然后就可以把你的内核，然后以及你的资源资源变更，然后就可以全部实现完成。OK, 那当我们在遇到了这些问题以后，我们来看云原生的这样一个版本，在买C克这里我们叫做集群版，然后它是怎么来支撑的，就首先计算规格和磁盘规格它是没有绑定关系的，因为现在存储和计算它的资源已经实现了完全的分离，然后它使用了云盘这样一个能力，然后并且我们是支持全部性能级别的磁盘类型，从啊最最低性能的SSD，然后到增强性能SSD，再到极速性SSD，那我们全部都支持，那你可以根据自己的业务需求，然后选择不同成本上面的啊磁盘类型，然后进行一个选择，那未来我们会提供啊。

单个节点的这样一个架构，并且使用最低级别的叫高性能云盘这样一个呃存储，然后它的费用会更低，那在这种情况下，呃，一些针对一些历史的大数，大量数据的存储的话，然后会有极大的在成本上的一个呃下降，然后可以方便业那个用户，然后在使用的时候降低自己的一个使用成本，并且我们在备份的时候使用了一个快照的能力，然后去进行一个。备份，然后在快照，并且配合数据库的啊锁备份锁的机制，以及双写这样一个机制的话，可以保证呃，在对磁盘进行。快照的时候，然后依然不影响你的D的操作，然后也不影响你的实际使用的一个性能。

还还有一点就是它可以做到非踌快速的恢复，我们现在在后台的话是每15分钟就会发起一个快照，那你每一次的呃，故障恢复以及。啊，你的资源变更都只需要追这15分钟的数据，然后就可以，嗯，就可以快速的完成你的资源变更，然后这个数据的话，我们测测试下来平均的效率大概在啊3分半左右，那基本上就就能够完成，如果你的数据变更量少的情况下，那基本上在分钟级别，然后就可以完成你的资源变更。OK, 然后在回档上的话，也提供了非常急速的，因为快照的存在，提供了非常急速的方式，然后去进行一个回档。而且我们快照的加载的话是异步加载的，会根据你的数据的啊热访问的情况，然后进行一个异步加载，比如说你要恢复1T的数据，并不需要你1T的数据全部从快照里面下载完成，然后你才能使用这个，它是直接秒级就能够挂载上去，同时会根据你访问的情况，异步的去优先拉取你访问的热点数据，然后来满足你的一个访问和读写的需求，然后其他的相对冷的数据，然后会异步的缓慢的加载回来，然后在这个过程当中，既保证了你的性能，又保证你的快速恢复。

啊，就用这样一个能力，然后去保障你整体的一个。啊，恢复的时间。并且在原生价格下面，我们不再受到呃受限的，然后物理资源的一个啊限制，比如说现在我们能买到的最大的啊一个规格，然后是一个90核，然后720g的这样一个啊规格，但是当我上了原生发现计算资源是可以啊纵向然后去增长的情况下，我们最大可以提供到512和2TB内存这样一个极大的。

这样一个规格，然后去给到用户去使用。啊，当然大部分的用户也没有这样的诉求，但是我们支持，然后在横向拓展上，通过我们的快照可以在5分钟内实现快速的扩啊扩展，并且支持独立的只读，也支持读写分离，然后也支持自动的故障转移，然后在整个故障转移上，然后和现在本地盘是没有啊太大的区别的，并且在单点的故障上面啊，它能够实现快速的治愈啊，基本上也是可以做到分钟级的治愈。OK, 在这样的架构下，我们依然要去解决一些技术问题，然后才能给用户提供非常好的一个体验，那比如说第一个云盘，对于对于本地盘来说，刚才有说到本地盘有一个非常非常巨大的。一个优势，那就是它的一个读写IO。然后以及。啊，读读写IO，然后它的IO的效率非常非常的高，然后它的IO延迟非常的低，那在这种情况下的话。

啊，我们需要用一些手段，然后来去增加它的一个性能啊，比如说第一个我们去做了一个BPV的这样一个能力，包括他有可能会重建以后并没有。去加载你的bar铺的一个数据，然后导致你的访问效率降低，那通过我们BAR2铺预热的这样一个能力的话，可以让你在极短的时间内去恢复你的一个性能情况。比如说你现在正在执行一个非常。快速的。呃，非常高并发的，然后一个比较热的一个请求的情况下，那在这种情况下，我们如果某个节点出现了跨区，它能够在分钟级恢复，但恢复了以后只是说我的数据库能够继续提供访问，但不代表我一旦恢复以后依然是在一个最佳运行状态，那就可以通过我们的包预热这样一个能力，可以在你恢复以后依然能够保持你在跨SH之前的那个呃，预热的map点上面，然后去保障。

你的一个。访问，然后依然是所大部分依然是满足你的p CT hint, 就是你的整个内存命中率依然是很高的这种情况，那在我们实射过程当中，整个预热的过程，然后是低于3秒的，那也就是说当我的实力在一分钟中以内出现库SH再恢复过来以后，那3秒以内我就可以将你的数据库性能恢复到和跨区之前完全一样，那不需要再经过一个数十分钟的一个缓慢的数据加载的这样一个过程啊，能够让你快速的恢复你的业务。OK, 然后还有一个能力的话，就是我们的一个原则写的能力，那这种就是由于IO延迟以及整体IO带宽的上限，相云盘相对于本地盘来说，相对来说是比较低的啊，然后。

My circlel, 然后又有双写的机制，然后来保证你不会出现part white这样一个呃问题，然后写分类的这样一个问题，然后导致说你的配角液出现损坏那。我们在这个基础上将。4次IO，因为每一个配置，然后它是16KB，然后每一每一个上去是4K，然后当你要写完整的一个页的话，你需要去有四次的IO，然后并且有W的存在的话，然后你还需要额外的再显示W的数据。会导致你的IO量出现翻倍。那我们都就通过原子写这样一个能力，将16K的一个写入，然后从4次lo减少成一次lo，并且啊，去掉了W这样一个。呃，双写的这样一个机制，用底层操作系统的能力来保障我。呃，整个页面就是整个16K页面的完整性和一致性，然后由由原子写这样一个能力去保障，那在这个基础上，由于整个云盘的磁盘上限，然后是恒定的，是限定的，那这种情况下，我释放了50%的IO出来以后，那这50%的IO就可以用于到业务的写入或者更新上面去，那我们从。

实际的测试上来对比的话。比如说我们执行外only这样的一个场景，那普遍来说我们有提升37%~50%，然后这样一个。这样一个性能，如果我们去执行red white这样一个混合读写的情况下，我们大概提升了7%~20%，那。White only这样场景下我们还能够理解，就是病例存写入，那为什么red white, 然后再关闭掉w white的情况下也能够上升呢？其实这个地方就跟云盘的LLPS总量上限以及带宽上限，然后这样一个。哦，规规格，然后是相关的，当您买了。

特固定大小的那个云盘的时候，它所提供的L性能也是固定的，那这个时候如果你能够释放一部分的啊外T相关的性能啊出来，它释放的这一部分就能够马上被啊瑞的这样的一个请求所适用，那所以在混合读写方面，它依然能够提升你的一个性。OK, 然后除了刚才说到的那些特性，然后我们在整个原生。啊，原生这样环境下面，然后还引入了非常非常多，然后在操作系统层面的优化，比如说代码端锁定多备份，然后or RC的on window I ruing, 然后网络配置调优啊，内核占用的内存优化啊，包括noma opno, 然后这样一些能力，呃，还有一个是我们最近还还在研究当中的，就是我们的啊超线程的核心的优化，就是大家都知道啊，超线程的话，实际上是把一个物理核心，然后虚拟成了两个逻辑核心啊，当你相同的业务，然后都在啊同一个核心上，或者不同核心上，它的表现是完全不一样的，那针对这样的一个问题。

我们现在也在去研究怎么去解决在原生环境下面，我们分配到不同核心上面，然后它能够提升你性能的这样一个解法，那保证你在呃物理核心上，然后能够发挥出你最高的一个性能，然后并且也防止L2缓存然后被污染，然后去降低你的效率，对于数据库来说，它是一个高内存访问的一个。呃，应用或者叫软件，然后数据库服务本身非常依赖内存的一个缓存，如果你的数据能够大量的缓存在L1L2的话，那甚至说L3，那你的访问效率一定，然后一定是非常非常高的，那后面的话，我们预计会在呃10月份，然后将这个技术应用到线线那个线网上面去，然后能够将啊超线程这样一个核心，然后利用到极致。

OK, 在使用了所有的提升的环境以后，我们通过啊c bech这个工具，然后在读写混合这样的场景下，当所有的呃优化点都同时使用的情况下，我们最高可以达到30%的一个啊性性能提升，那这也是为什么啊，很多时候我们在实测的时候，然后腾讯云的。啊，买这口测试下来的性能结果会比较好的一个原因。OK, 然后除了刚才说的我们所针对啊整个原生架构去做的。呃，技术上的一些特性以外，在产品特性上，然后也因为云原生这样一个存在分离的架构啊，提供了很多的啊特性，其中针对于和本地盘差异比较大的一些点。

第一个就是支持重新制度。由于之前我必须要靠不可见的备机来给。整整个数据库，然后提供可用性保障，那我的备机是不允许用户去进行访问的，因为你所加的比如说一些大的事物的锁，或者一些异常，会导致你的主从中间的同步会产生延迟，然后这样的延迟实际上是有损于我们的可用性的，那所以需要将被机隐藏，那由于我们现在存算分离以后，我们每一个节点都具备。自愈的这样一个能力，出现突发的跨区，能够在分钟级，然后将你恢复进来，那所以我们现在依然能够支持重新指读的方式，然后去保障啊，能够给用户使用的时候，然后去降低你的成本，原来你需要3个节点，然后才能去实现的一个能力，那现在只需要2个节点，然后就可以去做了，那从用户的使用成本上来看，然后它是降低的。并且如果你有多个节点的话，我们天然就支持多个重叠点之间是自动的附带均衡的，然后它能够通过统一的一个只读访问地址，然后去进行一个访问。

并且由于快照的一个加入啊，我们支持快速的增加节点这样一个能力，就从快照的节点增加来看，我们刚我刚才分享到了，就是我们是异步加载数据挂载的，所以我并不需要等待所有的数据从我的快照里面全部当下来，然后再去进行挂载，那这样的话时长是非常长的，对比传统的备份来说也也没有优势，我们现在只要确定挂载点以后，就能够快速的将整个数据库实际拉起，根据你的访问情况，然后先把热区数据先从。呃，快到仓库里面，然后进行一个恢复，然后先给到大家使用，然后其他的相对较冷的或者较温的数据再根据你的优先级，然后自动的加载回来，然后这又和刚才的那个巴菲铺预热，然后能够结合起来，因为通过巴菲普的预热，我能知道我需要优先加载哪一部分数据，那这一部分我可以告知到，呃，快照仓库，然后让他优先把这部份快照拉给我，那可以让你的。

呃，业务恢复的更快。OK, 并且针对这样一个可读的一个情况，我们把每一个节点的监控，然后都完全的暴露给了用户，然后用户可以通过节点的监控，然后去查看当前每一个节点的状态。OK.然后最后的话，其实就是这样一个能力的一个规划了，就是目前在Q2的话，呃，当前现在已经到Q3了啊，我们在Q2的话，已经提供了一键升级到集训版这样一个能力，并且也支持了PRO，也支持了独立的只读，然后相关的生产产品，比如说DB bring, 然后也支持了DMC也支持了，然后我们也提供了一键将存量的一个本地盘架构，然后升级到集训版的这样一个能力，然后用户的话是可以在控制台，然后直接进行升级的，然后避免了啊，用户还要去通过DTS啊这样工具，然后去升级的一个。

呃，难度就降低了，它的使用一个难度啊，然后在预计在Q3的话，我们要去支持高密高频备份，然后数命份备份下载以及极速全限回档，然后这样一个能力，然后在备份策略上，然后完全去对标，并且超越到啊本地盘这样一个能力，在最后的话啊，我们会开始预约SSAS，就是service的方式，以及我们想我们需要提供最大64T，然后这样一个存储空间的支持，然后存储的话，需要实现自动化的扩充的一个环管啊，自动化的扩容的一个管理，然后缩容的话也会提供，然后工具给他家，就大家都知道云盘是不允许缩容的，因为一旦收容你的文件系统有可能就会被破坏，那这也是我们要去攻克的一个技术难点，然后保证你的收容的情况下，也不会出现任何数据上的一个问题，OK.好，以下就是我的全部分享，好，感谢各位。嗯，感谢感谢陈老师，也再次感谢我们今天三位老师的精彩分享，好了，那现下面呢，就让我们进入今天的q ANDA环节，有请三位老师来为我们解答问题，那我们今天呢，一共有收集到10个问题，这几个问题呢，我就不一一去指定有哪位老师来回答了啊哪位老师看看能作答的话，那就请啊老师帮我们主动回答好了，那我们先来看观众提出的第一个问题，那针对有主从的架构扩容是可以在读和写的实例上都扩容吗？另外CPU啊，只是针对于数据库的扩容，那后期有考虑云服务器也支持CPU扩容吗？啊那这位观众朋友，我们今天啊是数据库的老师们，服务器的问题呢，我们就先不回答，后期呢，也可以期待一下我们的服务器专场，那第一个问题，呃请呃哪位老师来帮我们回答一下。

扩容是可以在读和写的实例上都扩容吗？我这边来说一下吧，就是扩容的话。呃，扩容的话，它的就是针对读写节点的话，是分开去需要去单独配置的，嗯，对于就是写节点的话，我们本身是一个主备的一个架构，然后它的主备都会去做扩容，那么他在ha切换的时候也能去提供，就是它的备机也能切换为主机之后，也也会提提供一个扩容之后的能力，那么就是读节点的话，就是只读节点的话，需要单独去适配这个能力。

嗯，就是单独去配置这个开启这个扩容的一个，就是在就是在在控制台上去单独配置，这两个是分开的。嗯，好的，谢谢老师，那我们来看下一个问题，嗯，我们观众朋友问到服务是订阅式的还是按需，是否能够检测到CPU的使用率自动扩容。嗯，要不还是樊明老师对不对，就是我来说吧，嗯，是是这样的，就是我们会持续监控所有的数据库实例，它的一个CPU的一个真实负载，然后当它CPU负载就是触发到达了，就是提前配置的阈值之后，然后就会自动发起扩容，然后如果是配置的自动扩容的话，自动扩容策略的话，这里是自动触发的，缩容也是自动触发的，当它的那个CPU使用使用率下降到阈值之下一段时间之后，然后这里就会进行缩容操作。

好的，感谢，那第三个问题，呃，自动扩缩容的策略会不会带来资源分配的抖动现象，会对用户业务有影响吗？嗯，昌明老师，嗯，好的，目目前来看，然后我们整个资源是相对来说buffer还是比较充足的，如果剩余的buffer不满足扩容的需求，然后这个时候您可以订阅一个事件，可以收，可以收到一个叫扩容，自动扩容失败的这样一个事件，然后可以对你来说，其实。啊产生一个提醒的作用，因为我们设计的啊，根本出发原因是为了解决用户的啊资源上限的问题，然后去解决业务上的问题，而不是说给业务造成一个资源抢占的这样一个风险，那这样的话，我们是会对资源进行一个预估啊，然后再去进行一个弹性的。

好的，感谢。嗯，同一台机器上的客户数据库如果都开启了弹性能力，那在同一时间段内大家都高负载了，这种极端的资源争抢会怎么处理？会不会出现问题呢？哪位老师帮我们回答一下。嗯，还是我来吧，就弹性控龙这个能力刚才也说了，就确实存在这样一个风险，那所以我们在资源分配时需要将组合从然后尽量进行打散一个分配，就确保你在主机上至少有留一半的buffer，因为我们现在整个啊CPU弹性的上限也就是两倍，那尽量去留一半的buffer出来，然后这个是我们在不断的动态调整的过程当中的，那在有一半buffer的情况下，理论上所有的实力都开始上面谈的情况下，也不会有这样的风险啊，但是也不敢保证说我所有的分配一定这样的，所以我会对实时的那个CPU使用率进行一个检测，那呃，采用的是一个先到先得的这样一个情况，虽然这样的概率非常非常低，但是你每100次或1000次，那总有一次有可能会发生这样的情况啊，然后如果发现本地的资源不足的情况下，然后剩下的排队要去弹性的那个。

哦，实力的话他是谈不上去的。好的，感谢，那第5个问题是发生扩容失败的概率会有多大？那每台机器是否都会有留有一定的buffer。机器C大概在老。嗯，然后这个还是我来解答一下吧，就是目前我们现网来说啊，统计下来，然后失败概率的话，大概是3‰到5‰，然后因为这这个数据会有一定的波动，然后就在3‰到5‰之间，然后它会有这样一个失败的概率，然后我们会预留buffer，刚才也说了，就预留大概一倍的buffer，然后在那个物理物理机上面去，然后因为它有一部分的那个使用的话，是其实是给重库，然后不可见的重库去使用的，然后那份基本上没有什么压力，OK.

好的，那第6个问题，腾讯云有计划支持吗？嗯，目前来说我们已经有啊TB circle for my circle的service形态了，那纯粹的原生的my circle的service的话也是有计划，预计在25年。好的，第7个问题，预测是弹性以后会支持，会支持到吗？嗯，预测式弹性的话，呃，短期内还没有计划，然后在未来长期里面肯定是有的，然后但是预测式和这种触发式的其实有一个很大的区别在于预测的精准度，然后是否一定能够匹配啊，用户的实际需求是不是有可能会造成啊成本的意外上涨，或者是说我的预测不够精准的情况下，会导致你的业务受损，然后都是有可能的，所以预测试和触发式应该是一个相辅相成的过啊，相辅相成的一个呃，两个能力，然后在这两个能力上，我们优先选择先做触发式，因为触发是可感知并且很明确啊，它能够保障你的业务在感知到异常的情况下，就一定能够给你去啊，进行相应的动作，而预测试的话会形成一个辅助，就是我们现在先做了，比如说自定义的啊，弹性扩容这样一个能力，那在后面的话，我们就会往预测室去弥补，说我在自定义这个周期里面，然后我如果无法。

啊，去进行准确的弹性，或者说我有预见性的进行弹性的话，那会做预测式的这样一个弥补，但是肯定还是触发式的方式，然后保在第一位，然后预测式的东西，然后去做风险防范。好的，感谢，那下一个问题，我们线上的朋友想了解，有计划支持磁盘扩容吗？嗯，磁盘扩容的话，在我刚刚说的原生那个版本里面，然后磁盘扩容就是无损的，然后呃，不管不管你扩了多少，反正只要它支持目前是32最大32T，那它扩容的情况下是完全无损的啊，但是呃，本地盘的版本刚刚说了，我是纯算一体的，所以它的整体扩容来说，是否能够做到无损啊，是否能够做到弹性，其实这个。

这这个点其实很难去满足，就是从现有架构来看，所以我们还需要针对这个点才推出了新的一个架构叫集群版，然后大家可以通过啊腾讯云的官网，然后去购买去看，然后它的整个呃，存储的控就是完全无感的。嗯，好的，下一个问题，刚才我们朋友问到高可用版是否可以直接升级到集群版，在能力上是完全对齐高可用的吗？还是说刚出来它是不是还不太完善？呃，目前它确实是刚出来的一个产品形态，所以它在功能上并没有百分之百的完全对齐，呃高可户这样一个形态，呃对于呃安全啊，比如说它当前不支持t t de加密，然后不支SSL啊，然后不支持审计，然后这块东西我们在10月份预计就会完全的补齐啊，但是如果然后是作为就是正常的运营，对SL t de以及审计没有要求的情况下，然后目前的能力是对齐的，并且在控制台是可以通过一键升级，然后进行啊，然后进行升级到呃集群板上面去，目前集群板开放的地域还没有，没有非常多，基本上是在一些比较大的地域，比如说北上广，然后其他地域我们现在也在补充当中，预计一直到今年年底，然后所有的地域都会和当前的本地盘的。

啊，地域实现一个对齐，然后能力上也实现完全的对齐。好的，那我们目前有没有客户在使用集群版，以及我们集群版的性能测试报告有没有呢？嗯，然后都已经有了，然后我们预计在8月中旬会全部把相关的信息都开放出去啊，因为现在每隔一段时间，其实我们都还在做很多的优化，相关的一个东西，就现在我觉得性能也也足够了，但是每周都还在做相关的性能优化，然后我会不断的迭代上去，这也是刚才提到的云原生非常好的一个，呃，特点就在于我的所有的优化都可以快速的迭代发布上去，然后这如果针对本地盘版本的话，其实它。

它的整体架构和底层的那个内核，它。改变起来非常的麻烦和困难啊，所以我建议是如果要用到生产的话，我建议是8月中旬以后要开始用，到那个时候我们相关的所有数据也会同步在官网上。好的，感谢感谢昌明老师，好啦，那我们今天的问答环节也到这结束了，再次感谢我们三位老师带来的精彩回答和分享，时间过得非常快啊，本次课程也进入到了尾声，我们再次感谢所有线上朋友对我们的参与和关注，下一次课程再见。