亮点回顾：应对高并发：数据库代理如何有效管理负载均衡、故障转移？原创

各位线上的朋友们大家好，欢迎参加腾讯云企业创新在线学堂系列课程，我是本次会议的主持人Lisa。腾讯云企业创新在线学堂是围绕企业业务需求，聚焦在数据管理、AI安全、办公协同等8大数字化需求场景推出的系列课程，携手腾讯云，创新驱动无限可能，共同开启企业成长新篇章。腾讯云数据库my circle是一种基于云计算技术的关系型数据库，它能够提供高可用、高性能、高安全的数据库服务，为中小企业客户提供可靠的数据库解决方案。相较于传统的本地数据库啊，腾讯云数据库my circle的优势在于，它可以帮助客户降低数据库的运维成本，提高数据安全性和可靠性，提升业务效率和竞争力。代理是一种在数据库与应用程序之间的中间层，可以对数据库进行访问控制、负载均衡、故障转移等管理。

它在现代化的应用程序中扮演着重要的角色，可以提高数据库的可用性、性能和安全性。腾讯云数据库MYSQL最新推出的集群版，解决了现有形态横向扩展受限、客户扩缩入慢等问题，为客户提供快照恢复、极速变配、暂停实力、备机只读等能力，在高稳定的服务上啊再添灵活性。好了，那接下来就有请我们今天的第一位分享嘉宾，来自银行的客户嘉宾王飞跃。王老师作为数据库的运维工程师，负责银行项目的运维工作，有着多年的运维经验以及后端开发经验，目前负责项目系统化运维工作，也感谢老师能在百忙之中抽出时间来参加我们的直播分享。

昨天我们彩排的时候啊，王老师都还在投产一线。那好了，话不多说，我们有请王老师给我们带来今天的分享，有请。嗯，好的主持人，呃，大家可以听到我的声音吧，呃，我首先一下共享一下我的屏幕啊，呃，大家好，我是王飞跃，现在是在一家国有银行做数据库运维相关工作，也很开心呢，能够得到腾讯的邀请，在我们企业创新在线课堂呢，给大家分享我们银行在数据库代理这个供应商的应用情况，今天呢，我是以一个使用者的角度给大家分享一下我的使用体验啊，后面呢，也有两位腾讯的专家老师给大家更为详细的介绍数据库代理的能力和实现原理，今天呢，我的分享会从。云数据库在银行业务中的应用场景，数据代理的介绍，还有呢，数据代理的功能，这三个方面讲起。

呃，首先呢，分享的第一个部分，我给大家简单说一下数据库在银行业务中的应用，可能呢，说到银行业务中的数据库应用，大家第一个反应呢，就是私有云产分布数据。嗯，这个其实也是没错的，核心的跑批啊，交易业务目前呢，在银行业中都是在私有云上进行的，数据库在银行业务中主要历经了以商业为主的集中式。逐步呢向开源和分布式呢进行试点，最终采用了国产分布式为主的转变，这主要来自于业务和技术驱动这两个方面，业务驱动呢，主要是随着数字化时代的来临，数据呢呈现了爆发式的增长，数据的存储和访问都面临着。重大挑战，传统数据库架构受限于单机资源的瓶颈呢？它并不具备这个水平扩展的能力，使使其海量数据处理能力较弱，就是难以满足新业务的场景需求。技术驱动主要体现在金融科技创新对技术、对核心技术的自主掌控要求。

啊，同时进入，同时呢，进行深入研究和场景适配的公关，就推进金融行业的核心技术安全可控标准的建设目标。好，那么我们说一下，就是公有云在银行业务中有没有应用场景呢？其实这个也是有的，现在各家银行都会推出自己的那个APP应用，特别是大行APP应用，已经不再是简简单单只有这种转账交易这个能力。还有很多的一些商城啊，社区运营活动，小游戏这些服务类的非核心业务。那么不少大呢，其实会将这类业务跑在公有云上，在公有云产品选择方面呢，现在的云厂商也会提供一些。金融级别的就是共赢。比如我们现在使用的云数据购买。采购的就是金融版，也就是三个节点，一主2倍的架构，选择金融版呢，主要原因就包括那个高安全，高可用。

我们在公有云数据库使用的数据库的代理能力，这也是今天呢要和大家分享我分享的一个经验，使用代理的一个经验。嗯，接下来要给大家介绍的呢，就是我们在业务中如何使用数据库代理的。首先呢，是大家带领大家了解一下什么是数据库代理，这个其实很简单理解，就是客户客户端数据之间的一个中间，也就是我们说的业务不直接连接数据库实例，而是先连接到代理，由代理去转发给数据库实例，这里转发呢可以是一对1 1对N或者N对N的情况。以前没有代理的时候呢，我们的业务逻辑代码是需要根据数据层面的实情况做一个代码修改。比如说呢，新增了一个只读，那么业务程序就要拿到新增的只读实例的地址，把负载手动均衡到只读实例中。

这样其实不。就是在扩展的时候会变得很复杂。另外读写分离的逻辑之前都是在业务层实现的，现在使用的代理他可以自己实现读写分离，业务就不需要去控制这个路由规则了。嗯。介绍完数据库代理的概念呢？就是我们来看一下代理的功能。嗯，整体从使用体验上，我觉得代理呢，最大的优势就是用于方便。数据库代理访问地址独立于原有的数据库访问地址，就是通过数据库代理的地址的请求。全部通过代理集群转发到。数据库实例只读实例，这样呢进行了一个读写分离。将读请求呢转发到只读里，这样可以降低对主库的负载，从而提高数据库的性能和可伸缩性。数据库代理的技术设计上有路由规则。因此可以实现自动转发，不需要我们的业务来做这个读写分离的规则。

同时呢数据库MYSQL还支持代理节点，代理地址以及只读的扩展，这样呢就方便了我们进行平方面的扩展，同时呢也能满足业务的快速增长。这里的节点只读都是支持跨可用区的，当然这样也保证了可用性。这样呢是满足了一个高可用的需求。当然大家也可能会有疑问，如果我们在业务和数据库中间加了这么一个中间件，那么中间件一旦故障应该怎么办？这里呢，腾讯云也给了我们两套不同的方案，大家呢，其实都可以服用。首先呢，是一个代理地址，可以有多个代理节点。每个地址我们至少保证有2个以上的节点，这样呢，节点出现故障不会影响我们的业务运行。同样的。业务逻辑可以用地址2来兜底。

其次呢，是。数据库代理也提供了故障转移的能力，一旦代理节点全部挂掉，那么代理节点呢？连接将全部转移到主实力上。当然这一方啊，这一方案呢，其实存在一个风险点，对吧，容易导致主实力负载过高，因此呢，这里是优先考虑选择多个节点。不同可用区的节点呢，来保证高可用。总的来说呢，对于使用者呢，只需要维护这个代理地址，这样就可以方便进行数据的管理和维护。啊，接下来呢，我们讲一讲负载均衡，这个当然比较好理解，负载均衡我理解的就是一个分配权重，客户端呢，大批量的请求过来了，按照一个权重分配到不同的数据库实例。从而提高系统的性能和可靠性。云社区这边呢，是可以自己配置那个连接权重的，根据业务需求进行灵活调整。

这样呢，就可以有效的避免单节点的故障，提高系统的稳定性和可靠性。嗯，腾讯的售后呢，也。也告诉过我吧，今年还准备上新的自适应的一个负载对应的能力，这样呢，后续呢，也不需要我们自己去设置这个权重了，代理就可以根据实时的负载和数据库实际的情况来做动态的这一个负载均衡。后续呢，我们也会积极的去呃，采购和体验一下。接下来给大家介绍的一个内容呢，房。房产证是什么呢？其实大家可能。在正常的使用过程中感知不到，但是一旦要调整到数据库，会有一些明显的感知了。比如说原本数据库主力。主实力啊，在配置升级的时候，或者呢进行切换的时候，这些变动呢，会有闪断呢，虽然可以在短时间内进行恢复。

但是对于前端的影响是比较大的，可能的表现就是用户在使用的时候会觉得卡顿内容。那么使用了代理之后呢。嗯。代理的连接主实力做调整是不影响代理连接的。相当于代理，这里和客户端的连接不会断，但实际情况是比较复杂的，大家呢，该做的那个重机制还是要做多几层保证，以保证了业务的稳定性。啊，除了自动读写分离之外呢，云数据库，蚂蚁搜Q的数据库代理还提供了事务拆分、连接池、就近访问等高级功能，在实际应用中呢，我们可以可以根据业务的需求进行合理的配置和优化，从而实现更好的效果。啊，今天呢，就是我跟大家做的一个简单的一些使用，我们使用呃MYSQL代理的一些体会体验啊，感谢大家。感谢王老师的精彩分享，如果有疑问的同学也请您在问答区留言，讲师会在问答环节为大家答疑解惑。接下来有请第二位分享嘉宾，来自腾讯云数据库高级开发工程师李书斌。李老师是腾讯云数据库代理业务负责人，专注云原生数据库开发多年，在数据库中间件领域有着丰富的经验。

工作期间，负责完成了腾讯云数据库代理业务的整体架构和功能设计，对于数据库代理中的读写分离、连接池、连接保持等功能有着深入的研究和大量的实践经验。欢迎李老师带来数据库代理实践，有效管理，负载均衡，故障转移主题分享有请，哎，好的，谢谢主持人啊，嗯，大家好，我是腾讯云的，呃，数据库开发工程师李树兵啊，今天我来给大家带来的呢，是数据库代理的架构解析和最佳实线啊，也非常感谢刚才王飞月老师的分享啊，就是王飞月老师也分享了这个，其实我们的PPT的，嗯，主体思路是差不多的啊，只是说是从用户侧和开发侧两个角度来解析一下这个数据库代理，好，那首先还是这个思路啊，就是我们为什么需要数据库代理，就是数据库代理呢，顾名思义它是要先有数据库才有数据库代理，对吧？那我们一开始使用数据库呢，比如说一开始申请了一个数据库，但现在一个单点的数据库呢，使用起来相对来说比较简单啊，我们可以直接建联上去执行查询就好了，但是呢，通常这个互联网业务发展都是比较快的，就如。

或者说我们的读请求量比较大的时候，我们呢，就会再申请一个只读实例，那我们希希望呢，这个只读实力能够去分担一些这个读请求的量，这样呢，能够实现这个主实力呢，就负载不会过高啊，那代码呢，可能就要相对复杂一些，比如说我们要实现一个简单的这个读写分离逻辑，然后去分离这个读写流量，那如果说这个请业务量继续增大呢，就是它架构就会变得比较复杂了，首先呢，我们申请了现在这个架构上是一主两层啊，一主两度，这样的话就是这个整个架构复杂之后呢，我们可能有更多的需求啊，首先是第二个主流实例呢，我们可以看到它的规格可能会更高啊，这样的话，我们需要把更多的请求转发过去，也就是说，我们要有一个负载均衡的权重的概念。

那还有就是说，如果指度视力发生延迟或者宕机的时候呢，我们能希望能把请求呢，发到健康的指度视力上去，还有就是说对于短连接呢，我们希望有一个连接池啊，再有就是说我们云上数据库有很多这个像升级啊，这种操操作可能会触发连接闪断的，我们也尽量尽量希望做到业务感知，那中综合这些就需求呢，其实都是我们在使用数据库中非常常见的这个那个需求或者说是痛点，那数据库代理呢，其实就是为了解决这些问题，但是呢，那数据库代理呢，首先是它有这个读写分离，负载均衡连接池，像我们刚才说的这些功能，另外呢，它也支持这种云上数据库在切换过程中的这种透明切换，能够做到这种无感的声降配啊，最大的还有这一个最大好处，就是说它开箱即用，就是说业务不需要做任何的改造或者适配，他只需要把这个连接的地址啊，给改成数据库代理的连接地址就可以了。

好的，那我们现在就来介绍一下这个，嗯，现在说说一下这个架构啊，嗯，我们可以看先看一下最下层，最下层这三个实例呢，就是我们刚才例子里提到的一主粮制度，那中间呢，就是我们的数据库代理的节点。嗯，我们可以注意到这个数据库的节点上，每一个都是有自己的独立的访问地址，那数据库代理呢，其实是在这些访问地址以外，又增加了一个独立的地址啊，一个VPC的费啊，通过这个VPC的网关呢，我们可以访问到后面我我这里面写的是两个节点，但是实际中呢，我们也可以申请的更多节点来保证它的可能性啊，数据库代理呢，它也有自身的规格，然后呢，我们可以根据自自己的需要呢，去调整这个节点数和这个规格的。

梳理，嗯，好，那这就是数据库带里的整体架构，那现在我们来说一下这个功能啊，首先先首先就是这个读写分离和负载均衡，那读写分离呢，可能相对好理解一下，读写分离就是说我们要把读请求和写请求分离开，那写请求呢，那那没有什么说的，我们只能录由到读写实例上去，因为只有读写实例有写业权限嘛，嗯，那读请求呢，读请求呢，我们就可以录由到读写实例上，也可以录由到只读实例上，这里面呢就有一个负载均衡了，所以说我们说的这个负载均衡呀，其实是读请求的负载均衡啊，那读请求呢，我们按照负载均衡策略呢，也是有权重的配比的。比如说我们在这里可以按这个规格的大小给它设置权重，但是呢，我们在使用过程中呢，就是如果说这个像这个比较大的实例，我们希望希望其他业务去用的话，也可以适当的调小这个权重，然后来达到这个预期的效果。

啊，对于这个负载均衡呢，刚才那个王老师也提到我们，呃，现在目前使用的线上目前使用的是这种静态的加权轮询算法啊静态的静态的算法的好处呢，就是它能保证请求这种分发的比例呢，是严格按照我们的权重去分发的，但是呢，它有一个嗯劣势呢，就是比如说我们刚才说有多个业务同时使用数据库的时候，比如说我们刚才说啊，我们有这个直连这个指读二这个节点的流量的话，那它可能会造成这个指段2的节点啊升高甚至打满，那整体打满之后呢，它就会对这个在静态负载均衡的情况下，我必须。去轮询整个数据库集群，也就是说任何一个节点打满都会拖慢和整个集群的速度啊，那这时候呢，我们呃未来也会推出这个叫动态负载均衡的算法，也就是说我当检测到呃一个指度实例啊，它的CPU负载过高的时候，我会减少给它发请求的数量，转而呢，去给其他请求，其他节点去发请求啊，从而实现一个载均衡，动态的负载均衡啊，这个大家可以后续继续关注我们的产品啊嗯，好，这是读写分离负载均衡，那这个读写分离负载均衡我们嗯当只读实力，呃我们都知道只读实力它这个复制啊，是有可能出现延迟的。

那当出现延迟的时候呢，我们有这个复值延迟阈值这个设置啊，这个设置单位是秒，嗯，比如说我们现在说这个值度实力，这个第一个指读实力发生了复值延值啊，它的复制延值是35，那高于这个阈值了，那我们就不会把后续的读立请求再发过去啊，嗯，这就变成了一个抑主抑制抑制度的一个架构，然后这样就会就是减小它的压力，那这样减小它的压力呢，也助于它，呃，这个复制延迟的快速恢复，等恢复之后呢，我们会继续恢复它的路由。

嗯，那这里大家可能就会有疑问，如果说我两个指读实力都发生延迟了怎么办？对吧？如果两个指读实力都发生延迟了啊，嗯，就是我们看到复制延迟都很大，都超过预值了，那这个时候呢？嗯，数据库代理会走一个叫付的，呃故障转移的策略，就是我们认为两个值都是都有故障，那我就会把读读请求发到主持力上去啊，这是一个负载转移，呃，故障转移的一个策略，但是这又回答了一个问题啊，就是我把很多毒流量都发到主持力上去，让那主持力可能承受不住，对吧？这个也是很常见的情况，那为了这个呢，我们有一个这个标题上写的有一个最小保留数的一个设置啊，那这个最小保留数的含义是什么呢？就是说还是上面这种情况，还是同样两个实例都发生了复制延迟，那在这种情况下呢，我们可以通过配置这个最小保留数，比如说我们设置最小保留数是1，那这种情况下我们就会最少保留一个制度实例啊停呃，留在这个读写分离里。比如说虽。

虽然发生了复制延迟，呃，两个都发生了复制延迟，但是呢，因因为我们有一个最小保留数的设置，所以我们有一个保底的机制，会至少保留一个当前复制延迟最低的，我们会选择一个最低的啊，然后去加入到当前读读写分离里，比如说我们的呃业务呢，至少有一个保底策略，不会被这种毒流量去击穿啊。嗯，啊，上面说的这个是这个读写分离，那么我们下面下面来说一下这个是高可用啊，高可用这个点呢，其实可以分为三点来讲啊，一点呢是代理自身的高可用，也就是说嗯，代理呢，它本身这个多个节点之间呢，是这种无状态的计算节点啊，所以说呢，它多可多多个节点之间呢，是完全对等的，所以说只要是多可多点多节点的架构的，就可以保证它的高可用。

那另外呢，是这个数据库的搞轨，数据库后指的就是后端数据库的切换呢，嗯，通过数据库代理呢，可以做到对客户端无感。嗯，然后就是这个整体架构的高可用，就是我们可以通过这种多可用区的架构，实现这种多可用区的容灾，那么我们下来来具体看一下啊。嗯，首先呢，是数据库代理的高可用数据库代理呢，嗯，可以看到，比如说我们这里面以两个数据库代理来举例，嗯，首先就是我们最下面有一个我们的管控系统啊，每个数据库代理的节点了，它上面都会有一个叫h agent啊这个这这样一个组件，这样一个组件它的作用呢，就是不断有心跳上报给我们的管控系统，同时呢，我们的管控系统呢，也会统不断的去进行这种拨测的探货啊，通过这两种机制来保证就是管控系统能够实时感应到啊每一个数据库节点，当呃，数据库代理节点当前的存活状态，当这两个机制任何一个机制报账的时候啊，嗯，他就会认为当前这个数据库代理的节点可能不健康了。

那不健康呢，它就会通过管控系统去快速的拉起一个新的节点，因为我们知道这个计算节点它没有状态的话，就不需要数据迁移，所以它拉起是非常快的，基本上就是是在秒级啊，我们就可以去拉起一个新的数据库节点，去替换原有的这个节点啊，当然刚才我们嗯王老师也分享过，就是我们还有一个保底策略啊，如果说这个两个节点同时失效的话，那我们可能会把这个流量切到主持页上去，去优先保证这个可能性啊，但这种情况如果是这种多节点架构的话，可能就没有那么常见啊。好，那这是代理的高可用，那我们后面说这个数据库的高可用，就是也就是说我们在数据库切换的时候，怎么让前端去无感知，那这个可能会复杂一点啊，我们来看一下就是，嗯，不管我们这个是这个升级这个内核版本也好啊，还是我们升级规格也好，还是去这个就是去迁移可能区，那它涉及到的呢，都是说一个旧的节点啊，去换到一个新的节点，在这个过程中呢，如何做到对客户端无感知。

啊，首先呢，我们所有的这个这个运维的操作呢，都是从我们的管控系统发起的。那第一步呢，首先嗯，管控系统知道我要我要做这个切换动作了啊，首先他肯定要准备好这两个节点，然后才能切换嘛，啊首先准备好之后，这两个节点之后呢，他去通知通知代理啊，我现在要开始切换了，那第二步代理呢，就会去断开这个到旧的主的主节点上的连接。啊，断开连接呢，也是为了防止这个这个双写啊，就是嗯，防止对这个旧的节点再去进行任何的修改，嗯，断开连接之后呢，嗯，数据库代理呢，就会阻塞客户端所有的连接啊，这个正常我们这个到主节点的连接如果断开的话，数据库代理会立即断开和客户端之间的连接，因为我们读写分离嘛，写流量是没办法进行这个转发的，所以说如果写流量进来的话，又没有主持力，我们是一定会报错的，所以正常来说，我们这个主持力的连接断开了，客户端链接一定是断开的，但是因为我们提前收到了管控系统的通知，说我们知道啊，这是一个运维操作，那这个时候呢，我们就可以阻塞客户端的连接，并且把他发的请求呢都暂存起来，这样客户端的表现是什么呢？客户端表现就是说我这个请求给他发过去了啊，但是嗯，在里暂时没有给我返回啊，只是执行的时间长了一点，但他不会感知到这个连接的断开，也不会有任何报错。

啊好，我们继续看啊，这个是这个数据库代理进入阻塞状态之后呢，啊，管控可以去就近点上确认啊，这个数据库代理是不是把这些连接都断开了啊，确认无误之后呢，才开始进行切换。

那这个切换呢，就是管控区会去啊新主节点上啊，把这个啊新的主节点提升，然后嗯，确立这个复制关系。之后这个新主节点就是可以用的状态，之后呢，管控系统就会啊，通知代理节点说啊，你现在新的主节点已经可以用了，你可以去去连接吧，那最后一步就是数据库代理会跟新的主节点牵连，并且重建会话状态，然后把之前暂存的这个语句发送过去。那这里面有一个很重要的呃步骤啊，就是我们要重建绘画状态啊，大家知道MYSQL连接是有各种各样的状态的，比如说我们这里面啊，写了一些状态啊，我们有未提交的事物啊，变量啊，预编语句，还有其他临时表所之类的，这这这些状态啊，任何一个连接关闭，在重新建立之后，这些状态其实都是清除了的，那我们要保证这个呃，所有这些东西对客户是无感知，那我们就要把这些呃，保证这些状态不会受到影响，那么对于这些这些，嗯嗯，这些状态来说啊，就是我们这个变量来说，是可以通过语句重放的啊，只有这个是可以通过语句重放，我们就可以，因为这个通常是set语句嘛，我们只要把这个set语句再再重放一次，那这个连接的状态就恢复了，那其他的这些语句呢，像尤其是事物，如果是一个未提交的事物的话，它这个第二步在断开连接的时候，它就不会立即断断开啊，这个不是一个立。

及断开的操作，它会等待这个事物提交啊，这个事物commit之后啊，我才会断开这个连接，然后断开连接之后呢，呃，就能保证我这个事物是完整执行的，这样我新建连接呢，就是也不会对这个事物有产生任何影响，然后还有像预编语句，我们会等待这个语序关闭掉啊，还有其他的这样一些临时状态呢，我们都会等待这些这些临时状态消除啊，消除之后呢，我们再断开这个连接呢，就是安全的，因为这样断开连接，我们机器状态连接再新建，新建上的连个连接呢，也不会再受到这些状态的影响。

啊，这个是后端数据库的一个高费用。啊，然后再有就是说我们这个刚才嗯，王老师也说过的，这个我们有多可运区的溶灾，嗯，大家可以看一下这个图啊，就是上面的话就是C业问，通过去做一个这个面有一个就近访问的机制，就是说他从哪里访问的，他就会转发到哪个可能去啊我们看可以看一下呃这个呃两边啊，一边是广州一区，一边是广州二区，嗯，这是举例啊，然后每个区呢，有两个数据库代理节点啊呃，广州二区呢，有一个数据，有一个指读节点啊，广州一区呢有一个主节点和一个指读节点。

那在这种情况下呢。如果发生故障，如果发生可用区级的故障，也就说比如广州二区啊，集体都挂掉了，那这个时候呢，我们可以看到这个剩下的部分，也就是说剩下的广州一区这部分还是有完整的一套这个机制，从业务到数据库代理到数据库节点，还是有一套完整的这个链路在的，所以说呢，我们在这种可用区级的故障的时候呢，仍仍能保持这个业务是正常运行的啊，这样就是我们的多孔区的容载，当然这里面也有一个就是说我们刚才说说的是故障的节点没有发生在这个主实力的这个可能区，对吧，如果主实力发生可能区的话，其实啊也是相似的，只是说主实力会先进行一次迁移啊，会迁迁移到它的贝壳去之后呢，我们再。去做这套多程序的流程，其实就是一样的。嗯，好的，那这样我今天分享的内容就结束了啊，感谢大家的呃，观看，后面呢，有什么问题也可以在QA环节下我们的提问，好，谢谢大家。

谢谢，谢谢李老师给我们带来的精彩分享，如果我们有疑问的同学，也请您在我们的问答去留言，等会儿我们的讲师啊会在问答环节给大家答疑解惑，那接下来就有请我们今天的第三位分享嘉宾，来自腾讯云数据库高级产品经理陈昌明。陈老师是腾讯云数据库MYSQL产品线负责人，在高可用解决方案、信息安全、系统规划、性能优化、灾难恢复与信息系统整合方面拥有丰富的实践经验，曾经也为网络运营商、银行、能源以及政府等各行业的关键业务系统提供运维升级、项目实施与管理、容灾建设等疑难问题的咨询与技术实施服务。欢迎陈老师给我们带来向着云原生进化集群新架构，助力企业轻松应对高并发。主题分享有请。

嗯，好的，感谢主持人，也感谢前面两位老师的分享，然后今天也特别开心，然后受邀来到呃创新课堂，然后给大家做这样一个分享，然后这样分享的一个主题呢，然后再结合数据库代理的基础上，我们再看一下，去横向看一下我们现有的架构以及未来的架构，能否更好的去应对企业的高并发这样一个场景，然后能够更好的协助业务去应对突发的呃业务性能需求，或是一些啊比较大的超过单个实力能够承载啊业务上限的这样一个情况，那如何去应对？好的，第一个的话。第一部分的话，首先要讨论的是我们为什么需要新的架构，呃，在讨论新的架构之前，我们需要看一下我们存量的就是传统的架构是怎么样的一个呃部署模型。

我们可以通过图上的部署架构可以看到，传统的部署模型是纯算，呃，纯算一体化的，它并没有。将我们的存储和计算，然后进行一个分离。然后在这个过程当中就会产生一定的限制条件，比如说啊，我们的物理的计算资源的上限，然后受限于整个物理机，或者说选定的物理机类型啊，导致它的上限并不并不足够高，或者说它的上限遇到的瓶颈。啊，会非常的大，然后在我们遇到。需要迁移或者说故障的时候，我们需要去。屏，我们需要屏蔽掉某一个节点，然后去做ha切换，然后这样的话，我的整个切换或者说故障恢复的流程会非常的长，因为基于物理机存算一体化的这样一个架构来说，我们需要通过h backup也好，还是说逻辑备份的方式也好，然后去备份我们的数呃，数据库的数据，通过这样的方式去做恢复的话，整个效率会非常的缓慢。

啊，然后比如说呃，1T或者2T的数据，我们以1T数据作为比方，我们进行物理备份或者逻辑备份时，那往往需要大概15~20分钟的时间，然后才能完成备份，那恢复的话也是差不多啊类似的时间，然后需要15~20分钟的恢复的时间啊这样的话，在一个啊配置变更或者说我们故障转移恢复的过程当中，就有可能会导致啊业务会有一个不可用的真空期啊，或者说它的高可用降级的一个真空期，在这样的一个真空期下面，呃，业务的可用性是很难去得到非常高的保障的，那就像刚才啊第一位老师分享说的，当金融级别的用户的话，他会为了更高的可能性选择三个节点，然后或是更多的节点的方式，然后去进行部署，那这样的话就通过多节点的方式，然后去规避掉了。

呃，我单个节点出现故障以后，我需要恢复时间较长的这样一个啊问题，但是随着我们业务的发展，我们的数据量越来越大的。啊，越来越快的增长，然后它的恢复效率和恢复速率其实很难。啊，其实很难跟得上我们整个发展的，它会随着你的业务的增长而变得愈发的缓慢。然后这是目前在传统的一体化价格上面遇到的非常大的一个问题。然后当我们从存量一体化架构遇到这些问题的时候，我们在寻求解决方案，然后在解决方案中其实有啊好几种，第一个是通过啊虚拟化啊的方式，然后来进行解决，还有一种方式就是现在大多数人在用的啊原生的方式，就是当我们把计算和存储进行一个分离，我们的计算完全用原生的整个架构来进行一个替代，那这样的话，我们的计算资源和值班值盘规格之间就没有任何的绑定关系，那就不会出现说我的计算资源和啊我的磁盘资源中间会出现某一方会被浪费的情况，我都可以最大化的利用这样的资源。

然后来提升我们的。降低我们的单位使用成本啊，同时这样的单位使用成本的降低，然后也体现在呃，我们自己对外的售卖的价格上，然后这也是直接将这种优势反馈到用户的一种体现方式，然后还有呢，就是。如果是存算分离的，当我再进行配置变更或者是啊故障恢复的时候，由于存储是不需要单独再进行一次额外的恢复的，那它的恢复时长跟你的数据量本身就没有任何的关系啊，比如说你恢复呃500g的数据和恢复20T的数据，那对于整个恢复流程是完全相同的，我可以异步的通过。

呃，云盘的能力，然后去拉取到你的一个备份的镜像，或然后去快速的将你的数据库拉起，然后这样的话可以将整个恢复流程，然后从之前说的1T5大概要花啊15~20分钟的时间，然后完全降到一个分钟级，就一分钟，然后就可以搞定。然后在实际的呃过程当中啊，我们还会使用一些比较高频的呃快照的方式来降低整个数据同步的延迟啊，除了我们可以通过一分钟来拉起以外，那在整个切换变配以及故障恢复的流程当中，还会有一个数据同步的这样一个流程，而这样的一个流程我们是通过高频快照的方式，就每15分钟，然后去打一个快照啊，去记那个记录增量的方式啊，来降低它中间啊所数据同步所需要的一个时间间隔，那保证尽可能在保障呃整个变配流程里面，然后它的时呃时间是非常短的，然后通过我们普遍的测试下来的话，基本上平均时长在三分钟左右，然后就能完成纵向的一个。

嗯，配置的变更，然后同时在故障恢复里面啊，由于当我出现异常以后啊，直接拉起，所以对于他来说，整个故障恢复呃，流程大概只需要1分钟，那那基于这样一个特点的话，然后在云盘的架构下面还有一个物理呃存算一体化的架构无法实现的一个能力，然后这个能力就是我们可以将我们当前的用于传统。价格下面用于做隐藏备机的这样一个备库，提供给用户去使用，那从另一个方面讲，它进一步降低了用户的使用成本，那传统价格下面啊，所有的隐藏的备机都是不可被用户访问的，然后对用户的使用成本来讲，也非也为了可用性而额外付了一部分的费用，那这部分资源在可以快速恢复的这样一个情况下，我们可以提供给用户去使用。

那。在这种情况下的话，对于用户来说，他又节约了一笔额外的计算资源的费用，这样呃，就节约了一笔额外的计算费用啊，可以可以实现到资源的最大化利用，那对于用户来说，它的性价比是更高的，它也能花相同的计算资源去获得更多的一个性能啊。OK.那基于刚才所说的，像比如说税务啊代理，它是支持一个横向扩容的这样一个能力，在传统的那个纯算一体化的这样架构里面，他要去做横向的扩展的话，就像刚刚说的，他需要去通过备份去恢复，恢复的过程当中还需要做主从的同步，那主从的。

数据同步的话，那这个时间其实是不可控的，那通过我们的高频快照，通过我们的。啊，快速的快快在扩展，我们可以很快速的将我们的指读节点或者说只读实例，然后横向的快速的扩展啊扩展出来，扩展以后再通过PRO的一个呃负载均衡的能力，然后将新的负载，然后分发到啊新的只读节点1或者只读实例上面去啊大家可以看到图上面其实对只读来说，其实有两个名称，一个叫只读节点，然后一个叫只读实例，然后这个在新的零分版里面是代表着不同的含义，此读节点和读写节点中呃一共组成了一套集群，然后它的上限是最大具备5个节点，然后它们组成的集群里面，然后是可以随时将其中某一个子读节点切换为读写节点的。然后在只读实例上，我们又额外提供了一个只读实例。

然后这个只读实例和只读节点最大的不同是在于它是独立的，它的规格和读写节点是可以完全不同的，但只读节点是要求和读写节点啊完全相同的规格，因为你随时有可能需要把只读节点切换为读写节点来满足业务的一个诉求啊，所以是有这样一个硬性的要求和限制，但是只读实例的话，对于他来说我们是不参与切换的，那在参数配置上，在你的规格配置上，然后都可以和读写节点或只读节点是可以做到完全不同的，同时你的访问路径也可以通过B去单独的进行配置和设置。然后在横向的扩展性然后解决的情况下，我们还可以通过由于是存上分离的架构，我们可以借助最新的计算平台，然后去使用最新的计计算资源，然后最高的情况下，纵向我们可以去扩展到512和以及2T的内存，其实对于MYS狗L这样一个关于数据库来说啊，512核以及2T的内存这个规格已经非常非常的巨大了，对于大多数的马SQL应用来说，其实啊。

8核以上的那样的规模都很少，一般是在啊，马上也到618，大家也知道，就是快到促销或者说某些特定活动的时候，然后会需要这样一个呃，扩展的一个能力，所以我们也具备说能够用到最新代次，然后最强的一个呃，计算资源这样一个能力，可以纵向的然后去实现扩展，同时横向的话能够保障。嗯，快速的将它扩容出来，然后通过proceed负载均衡能力，通过它的读写分离的能力，然后将我们的链接和请求分配到不同的。呃，节点上面去，然后使得它的负载啊，能够得到均衡的释放。OK.然后除此以外，这其实最大的挑战就在于我们从一个纯算一体的架构迁到。存在分离这样的架构里面来中间存储这一块的。

的性能，或者说链路的变化所带来的很大的挑战就在于呃，网络的存储，然后肯定是比本地的存储，而它的极限性能。然后是要。更低的，然后响应效率也更低。那么我们如何去防止说。在网络去访问，就网络IO。比本地IO要低的情况下，我们怎么去提升它的一个性能，或者说降低它的一个瓶颈，然后会成为呃数据库使用原生的时候非常大的一个啊挑战，因为在使用原生你也可以选择啊local bv的方式，然后把啊存储放在本地，但这样就失去了存算分离这样一个目标了，所以我们依然坚定去使用啊云盘这样一个架构，然后在这样做的时候，我们会发现首先要解决的是两个问题，第一个啊吞吐量，第二个是。啊，IPS的一个响应的问题，就是IO的一个延迟问题，首先吞吐量的解决，我们主要是。

呃，主要是通过。呃，原子写的方式，然后来进行解决的，就是我们在呃最新的就是云盘版本里面，然后上线了，呃。一个原子写的一个能力，我们保证它能够以16K，然后作为一个原子的方式，然后写入到磁盘上，然后这样的话会避免啊，我们出现一些写分类的问题，然后为了专门解决这样一个问题的话，MYSQL原生带的有w white的这样一个，但是w white这样一个特性的话，会导致。我的写入啊，我的写入量会比。正常的血流量会double会翻倍，那解决了这个问题以后，我的血流量对对比传统的必须得看w white的这样实例来说，那我的血流量就降低了啊。最多最多50%，那我的使用性能就得到了翻倍的一个提升，那在这种情况下，我们存储的网络带宽，网络带宽所带来的存储的瓶颈，然后就被缓解了非常的多，那第二个就是LPS的响应问题，那LPS响应问题其实很多时候都会通过一个方式，其实就叫做内存缓存，这这个这个是数据库自带的，那我们如何去尽可能的将数据缓存到就热点数据，然后缓存到WiFi里面去，然后或者说在一些异常的情况下，然后将这些。

热点的数据，然后缓存在buff个中，所以我们又做了一个新的内核的特性，叫叫做BP预热，那通过BP预热的方式，我们可以我们可以将啊节点重建，然后或者说正常的HHA切换以后，将热点的buffer的。嗯。整个的历史的信息，然后在新的节点上，然后进行一个快速的加载，那通过这样的加载的话，原来需要大概1~2分钟才能预热的数据，对于我们来说只需要一秒一秒钟就能够快速的加载到8F里面去，然后保证了业务在出现故障以及新垃圾实力的时候啊它的个。

呃，它的一个性能，然后抖动的一个问题，那在这个方面呢，我们就去做了呃，很多的优化，还有一个我们做了一个呃内存的，呃二级压缩的一个能力，就尽可能的将更多的。呃数据然后再缓存在内存里面去，然后去降低和磁盘的一个交互，那这样的话有非常就可以明显的缓解由于呃云盘所带来的呃带宽和IO响应所导致的性能下降的问题。然后这个是我们在云原生平台里面要去解的一个呃问题。啊，这个就是刚才说到的原子写啊，刚才说到的原子写这个能力的话，其实我们在实测上面来，然后对在就是4并发，然后4和16，呃，10和16g这样一个规格下面，然后我们能够获得啊将近50%的提升，然后目前实施价格大概是35%~50%之间，嗯，然后由于。

云盘它的整体的IO上限是恒定的，然后如果你能够释放一定的外IO，然后它这个外台IO是可以被分配到RA的IO上面去的，那也就时候如随着你的毒的，呃，随着你写入的IO的总量减少，那这部分被释放的性能其实会体现到毒上面去，所以为什么在相同的情况下，虽然我们解决了写入的一个性能带宽的总量问题，那最后体现出来在读写混合场景下，它的总体的性能也得到了一个增强。OK, 除了这以外，我们也结合了线上的呃优势，就是存算分离这样一个优势，其实我的计算的节点是可以随时去更新，然后对比传统的成长一体化的呃这样架构来说，它的更新频率会更高，会呃快得多，那我们就可以。

通过灰度的方式，然后以及呃验证的方式就快速上线很多我们这里测试过并且有效的那个提升性能的方式，比如说代码段啊，锁定多备份，呃，Or RC on window l ru呃，网络配置一些优化，然后内核占用内存的一个优化，然后nova OS SP lock相关的优化，那通过以上的种种优化，我们得到整体一个性能15%以上的提升，然后这个也体现在了我们最终版本里的一个啊差异。嗯，然后这个是实际测试的一个结果，就是当我们没有去提升啊，没有使用啊，这些优化前和优化之后，然后基本上有一个30%~50%的一个性能提升，然后使用的测试方法，就是传统的随便去的压力测试方案。嗯，OK, 在新架构特性里面，然后刚才也说到了，我们是可以通过快速的增加呃横向去增加我们的呃节点，然后来实现一个横向的扩展，同时你也可以配置PRO，然后来进行一个负载的均衡，然后以及读写分离，然后自动化的去实现啊还有一个就是从一子读，就刚刚说了，我们由于我们的单个节点的恢复非常的快速啊，所以我们可以开放隐以之前呢，对于存在一体化架构来说，隐藏的飞机，然后给大家进行访问，那这样的话可以进一步的降低用户的一个使用成本。

OK, 然后最后的话啊，可以同步一下那个我们在今年在呃云盘版本的一个呃规划啊，目前银行版本已经在官网呃上线了，然后大家可以通过在官网呃去进行购买和使用啊，然后我们预计在Q3和Q4的话，会带来书面备份啊，高频下载，包括极速全球回档这样一些啊，在原来的存算一体化架构上面很难去实现的一个能力，然后在当前的架构下啊，都是有径可以去实现的这样一个技术和能力，嗯。

好了，我今天的分享就到这里结束了啊，感谢各位。嗯，感谢感谢陈老师，也再一次感谢我们今天三位老师的精彩分享啊，那现在呢，我们就进入今天的QA环节啊，也和大家说一下，由于我们的第一位客户嘉宾王老师他所在的银行啊近期项目投产，现在呢人又去生产一线保驾护航了，不过没有关系啊，后续我们的直播回放以及课件都会上架在腾讯产业互联网干货库小程序，大家可以在聊天区留言，我们会第一时间转发给王老师。好了，那接下来我们今天的问答环节就由李老师和陈老师来为大家解答，嗯，首先我们观来看看线上观众提的问题啊，第一个问题是给到李老师的，说你好，李老师，那代理这里有没有SLA的保障，我理解如果现在连接都打在代理上，那代理的可用性的保证还是需要评估的，嗯嗯，李老师，是的，这个我这边的SI的话，可以具体后面去看我们的这个官网文档，具体是多少的话，这个以官网文档为准啊，应该是和这个我们的数据库是一样的，就是同样都是一样的这个S去算的，然后对于这个高可用的话，我刚才就是分享里也讲到了，就是说我们现在也是这个通过了多种机制吧，去保证它的可用性的，然后不管是它单节点故障啊，都可能去故障啊，其实我们都有相应的方案去解决，然后包括这个其实对于我们来说最重要关键最重要的工作，也就是说如何保证这种可能性。

啊，我非常理解这个客户这个这种担心嘛，因为毕竟中间加了一层对吧，那肯定是这个，呃，各种风险都要考虑到，但是也请客户相信，这也是我们的，就是工作的重中之重，就我们最重要的目标就是维持这个呃代理的稳定性啊嗯，好的，那看看我们观众下一个问题，呃，请问连接状态保持这里会有场景的限制吗？命中了不支持的场景，是不是代理和业务的连接也会断掉？

是的，对，就是刚刚才我分享里也提提到，就是房产段，这个不是说所有的场景都能兜得住的，就是有的场景的话就有的，嗯，连接的状态我们是无法恢复的，但是这个这里面的话，我们也在持续的去做这个工作的推进啊，比如说像我们刚才讲到有一个叫预编语句嘛，就语句这个的话，就是它有些SDK呢，它就是用这种方式去执行的，那如果是现在的话呢，嗯，就我们就无法支持这种这个特定的SDK，呃，下面的方程段，但是呢，未来我们也会不断推进，这个也在计划当中，就是呃，我们可能会把这些场景啊依次的去解决掉啊，当然有些场景解决不掉的可能没办法，但是这个也是我们的努力方向之一，就是我们会不断推进这个方产灯功能的这个演进，嗯。

好的，嗯，然后观众朋友们问，如果发生了AC故障，流量会不会对存活AC造造成冲击，是的，这个这个就是我们要考虑到的问题，其实不光是可用区的故障，就是对于PRO来说，PRO可以有多节点嘛，就是刚才我说的就是就算我们是单区下那两个节点，当一个PRO节点发生故障的时候，流量也会打到另外一个PRO节点上，所以说这时候我们要注意到，就平时我们使用的时候，比如说我们是两节点，那我们就是平时使用的，如果呃，看这个CP已经是接近50%了，那当发生一个节点故障的时候，另外一个节点很可能会打满，所以说我们在平时使用时候就尽量要关注一下，就是平时的使用情况，然后刚才嗯，这个客户提到这种A的故障的时候，我们也要预备好这种备案，因为这种程序故障毕竟不是天天会发生，就是它发生概率不大，但是如果说我们要做这种备案的话，就要预备好，就是尽量多。

留一些八法，然后尽量留出这个缓冲的余地，然后这个也要看平时业务的使用量，这这个具体大家评估的话，可以是这个转发线上的实际场景，然后给我们的客服同学，然后我们可以大家一起来讨论一下，嗯。好的，第4个问题是想咨询一下李老师，重重新负载均衡这个能力后台是根据什么样的规则来判断访问不均衡的呢？那这里和刚刚说的自适应的动态均衡是不是一样的原理啊，对于这个重新负载均衡，这个不是说我们后面的这个负载均衡，它是指某些情况下呢，就是呃，我刚才也提到就是呃，MYSQL它的连接呢，都是有状态的，那这些状态呢，决定呢，就是我们很多特性呢，是连接级生效的，也就是说我们可能有些配置改完之后呢，新连接是只有新连能生效，老连接是生效不了的，所以这个重新负载均衡呢，指的是呃。

呃，其实这个重新负载均衡是，嗯，它的作用就是重新那个建联一次，就是让proc把当前的连接全部断开之后呢，触发客户端去进行重连，实现一个重新负载均衡，这个用来解决就是某些参数啊无法生效，或者就是一些旧的实例的时候，呃，对于一些旧的实例，它可能新加一个只读实例进来的时候，它的存存量连接是没办法对这个新的只读实例去建联的，针针对这种情况下去做的这个重新负载均衡，其实它并没有什么算法上的限制，只是说它会去重新，呃建立一遍连接，然后这样达到这个重新负载均衡的目的，嗯，是这样的。好的，那接下来第5个问题是，如果只读突发不可用了，新连接应该可以走到正常的只读上，但是之前连接在不可用只读上的连接呢？能否切换到正常的只读上呢？

嗯，是这样的，就是我们这个负载均衡呢，就是连接呢，它是一对多的，也就是说一个客户端连接对应的是多个后端连接，所以说并不存在说呃，问题的只读实例上的连接，需要迁到其他的连接上，因为其他的只读，其他的不管是主实力还是只读实例，就是已经有存活的连接了，已经有可用的连接，这个时候我们只要把请求发过去就行了，然后这边的有问题的连接我们直接断掉就可以了，后面他再恢复呢，我们再重新跟他建联就可以了。嗯，是这样，好的好的，感谢李老师，那我们看看观众朋友们带来给我们下一个第6个问题是给到陈老师的，请问集群版使用体验上和高可用版会不会有很大的差异，那集群版是ARM架构吗？业务上需要改造吗？陈老师？嗯，对于业务来说并不需要改造，但是高可用版本来说，它的差异目前呢，还是在一个功能补齐阶段，然后特别是高可用已经开发迭代了这么多年，它目前所具备的很多能力，比如说跨地域的一个在备，然后这些东西都需要，比如说通过DTS来进行一个补全，它都有对应的类似的解决方案，但是它原生有一些相关的能力啊，并没有，并没有这么快的方式去补齐，但它主要是通过一个新的一个架构来给用户提供了一个更快速的变配啊，变更，然后以及一个计计算规格和磁盘规格中间绑定关系的一个问题，那在这个后面的话，我们也会投入非常非常多的人力和资源，然后到这样一个架构里面去快速将它补齐，因为它对未来的整个发展来说，它是一个我们确定性的一个方向，然后并且在这个架构上我们可以做的呃，能力以及所实现的功能范围都会远远比高可用法更多。

啊，所以目前来看啊，主要是在啊，灾备啊和一些SSL加密啊等这种相对来说用用量不是非常大的这种功能上，然后还需要一些补齐，我们预计在今年的9月份能够将存量的一个能力，然后呃全部补齐完成，然后当前的话啊，还有部分的能力，然后还在试飞过程当中。

好的，谢谢，那下一个问题是集群版的变配流程，嗯快吗？为什么现在高可用版呃比较慢。呃，刚才有说过，就是呃高层版本它的备份的话和恢复的话，都是说用hbup这样一个工具去做啊，所以在做的过程当中都会有一个根据你数据量的备份和恢复的这样一个时间，并且在备份恢复完成以后啊，它都会有一个数据一行对比的一个过程，因为按贝up普并不是一个百分之百可信的一个啊备份的工具，虽然你可以去校验你的啊备份的文件，然后是否有效，或者说校验它的MD5值是否一致，但是它的备份和恢复和呃是有一定的概率，虽然这个概率非常非常低，有可能一年遇不到一次，但一旦遇到啊，数据库作为作为存储数据的数据库来说，一旦遇到，比如说数据不一致，或者说数据损坏的话，那这个的影响会非常的巨大，所以每次我们都会进行一个数据进行对比，那它主要就由啊恢复啊传输呃同步以及数据数据一行的对比，然后这几个部分组成，但是在呃集群版上面的话，它是没有数据1的对比啊，以及恢复的这个。

的过程的，它的恢复过程，不管你的数据量到底有多大啊，是一个固定值，然后我只要挂载以后能够直接拉起来就好，它需要的只是一个数据同步的时间，而我们每15分钟就会去做一个增量的快照，那这样的话啊，就会呃，使得你中间所需要数据同的时间是极需短的，因为大部分情况下你需要去做呃数据同步的时间也不会超过15分钟，所以这样的话可以保证你的变配同步的逻辑，然后都会非常的呃简单，并且由于它是物理级别的一个。

呃。磁盘级别的一个快照，所以它并不需要去做出引一对比，那相比于高可用来说，我们就节省了非常非常多的时间。好的好的，感谢那我们，呃，接下来一个问题，嗯，高可用版本的备机有计划开放给客户使用吗？嗯，没有，因为高可能存在一个很大的一个问题，就是存在一体化架构，如果它某一个，如果它的节点然后损坏的话啊，它是没有办法快速恢复的，其实和呃，集群版就是云盘的这样一个版本对比起来，其实它最大差异在于恢复效率和速度上，那如果把备机开放的话，如果因为备机的操作而导致较大的主动差异，或者说呃，文件损坏，或者说导致一些异常的情况，那会导致你的可能性受到非常非常大的影响，那对于集群版来说，它只需要将存储重新挂载在一个新的计算节点上就可以去使用了，它的风险层级是完全完全不同的，那根据我们的啊风险评估，然后以后那我们才将它的一个从绩。

呃，只读的一个方式，然后开放出去啊，在高可控版本里面，那为了你的高可用性，要之所以它的高可控版本嘛，那我们是不可能开放重击的只读的，因为这个会大大的损伤它的一个可能性。好的，嗯，接下来这个问题，云原生集群架构在灾难恢复方面有哪些优势，嗯。OK, 刚才有说到，就是我们的呃，存储和计算是分离的，它的最大的优势是在于你某一个单个节点的呃跨式或者说异常，然后它都可以通过快速拉起的方式，然后将你的计算节点，然后再将你的存储呃，存储磁盘，然后再重新挂到新的计算节点上，所以你的整个过程来说啊，是非常的快速的，并不是并没有任何的数据恢复的过程，那这个。

整个过程的话，然后再加上了一个BP预热一个启动的这样一个话，基本上可以缩短到一分钟以内啊后对于正那个对于高可用的纯酸一体化的这样一个架构来说的话，那它会它就没有办法去恢复，因为你的数据文件已经不可被访问和读写了，然后哪怕你能够被访问读写，你也涉及一个数据啊搬迁的一个问题，那所以你是没有办法做到快速的恢复的啊，就基于这样一个架构，所以我们的恢复对比高客户来说啊会啊快非常的多。好的，再来看一下最后一个问题，我们线上朋友想了解一下，保证数据的快速读写和处理的优化措施都有哪些？呃，OK, 是这样的，其实有两，呃其实有两个方面，刚才包括在啊整个分享过程里面，然后更多的是说到一些BP预热的啊一个方式，其实还有一个就是在于嗯，就是云盘的异步挂载的一个问题，对于云盘来说，或者说对于存储来说，它挂载到计算节点上，并不需要将它所有的数据都完全从网络上下载下来，或者说呃，需要将快照download下来，然后才能够去访问，然后通过快照去进行快速访问的时候，实际上是有一个啊先后顺序和一个过程的，它会识别到你的一个热点区，然后会优先将你的热点，然后啊登录上来，这样的话会使得你的恢复过程会非常的快速，比如说你有啊2T或者12T或者20T的一个数据量，但对于你的热点数据来说，很有可能就只有几个G，所以它会优先将这一块用于启动和呃热点的数据，然后先登录下来以后，然后去恢复你的一个业务，然后后面相对较冷的数据再异步的恢复到现在的磁盘。

传上，那这样的话就在啊，整个恢复过程当中，不会影响你的一个读写，并且可以快速的恢复你的业务。好的，感谢，感谢陈老师给我们带来的详细的解答，也感谢李老师，嗯，那我们本次的问答环节就到这结束了，也再次感谢我们今天三位老师给我们带来的精彩分享，时间过得很快呀，我们本次的课程也进入到了尾声，再一次感谢大家的参与与关注，我们下一次课程再见。