亮点回顾：灵活扩展新选择，集群形态助力业务发展原创

各位线上的朋友们大家好，欢迎参加腾讯云企业创新在线学堂系列课程，我是本次会议的主持人Lisa。腾讯云企业创新在线学堂是围绕企业的业务需求，聚焦在数据管理、AI安全、办公协同等8大数字化需求场景推出的系列课程，携手腾讯云，创新驱动无限可能，共同开启企业成长新篇章。腾讯云数据库MYSQL是一种基于云计算技术的关系型数据库服务。它能够提供高可用、高性能、高安全的数据库服务，为中小企业客户提供可靠的数据库解决方案。相较于传统的本地数据库，腾讯云数据库买circle的优势在于，它可以帮助客户降低数据库运维成本，提高数据安全性和可靠性，提高业务效率和竞争力。腾讯云数据库my circle最新推出的集群版，解决了现有形态横向扩展受限、扩缩容慢等问题，为客户提供快照恢复、急速变配、暂停、实力机读等能力。

在高稳定的服务上再添灵活性服务。除此之外，云数据库MYL还提供数据库代理、数据库智能管家、CPU弹性扩容等多项便于运维的能力，帮助客户智能化好数据。本次课程将有3位腾讯云的专家为您带来分享，智能运维如何让中小企业数据库管理更高效。在分享过程中，如果您有任何的疑问，欢迎您在问答区进行提问，我们的讲师会在最后的QA环节为您解答。同时呢，您也可以通过聊天窗口发表您的意见和建议，期待您的反馈。好了，那首先呢，就有请今天的第一位分享嘉宾，来自腾讯云数据库高级产品经理何威。何老师作为腾讯云数据库智能管家DB brain产品的负责人，专注在MYSQL生态产品多年，对于数据库的可观测性、可运维性及智能诊断有深入的研究和见解。

也曾负责数据库管理、数据库传输服务等生态产品领域。何老师今天的分享主题是dp brain全链路分析，祝您深入洞察数据库，有请。嗯，好的，感谢主持人，嗯，感谢大家来参与今天对DB的一场一次分享，我是腾讯云数据库产品经理何微。那么首先我们介绍一下。嗯，这是今天的一个分享目录，嗯，DB Bo是什么？然后对DB泵全链路分析的介绍，然后DB泵实时诊断和巡检的介绍。然后最后一部分是DB部分的使用经验的一个总结，那首先我们看一下DB部分是什么啊，DB部分数据是数据我们数据库智能管家的一个缩写，那是腾讯云推出的一款为用户提供数据库性能优化，管理诊断的数据库自制云服务，那我们主要是将腾讯在数据库啊领域内多年的啊一些运维经验的沉淀，将它浓缩成一款云服务产品，那希望能够服务到云上和云下的企业啊，助力大家保障数据库运行的安全、稳定和高效。

那DB泵呢，核心是提供了一个7×24小时的实时无人值守的运维自动诊断，那么除了诊断出问题之外，我们还为还为这些问题提供了深度的分析，并给到优化的建议，那么借助于DB部的呃诊断和运维呃呃助力的那么的功能，那么我们可以有效的降低数据库运维的成本，提高数据库运维的效率。DBB呢，在云上和云下均提供了多种形态的啊支持版本。

那DBB呢，是在2019年就在公有云上正式的推出了，那么我们当时是以my circleq生态产品为基础，推出了基于my circle的啊DBB的服服务，那接下来我们推出了TD circle my circle, 还有TD circle-C，那么进一步的最近几年我们推出了针对呢no circle产品线的支持，包括了radius和mango DB, 并且我们也推出了私有云的版本啊，输出在了国内的一些核心的私有化领域。那目前DB部呢，我们可以看到在公有云上主要包含两大的功能板块，一个是实时诊断和健康巡检，另一个就是我们新推出的全内容分析功能，实施诊断与健康巡检的核心刚才有提到就是我们的进实时异常诊断和优化建议，并且根据我们的啊优化建议，我们提供了相关联的分析优化的功能，例如慢scol的分析，然后应急的处理，如绘化的管理一些条件Q，那么异步，那么我们还可以异步的去对数据库进行健康的巡检，留下数据库的健康啊，健康情况的一个存档。那所有的这些功能呢，我们都是会给到用户一个可视化的呃统计呈现，方便大家呃快速的抓取到主要的信息啊，这是我们DB部多年以来，嗯，最核心的一个功能板块，那近期我们新突破的一个功能板块就是全面的分析，也是今天想分享的一个重点，那么我们是基于审计日志对数据库的运行。

情况啊帮助用户做到深入的洞察，我们可以做到circleql明细的啊实时的解析查询，然后基于circleql明细我们做到事物的啊解析查询，然后同时将业务与circleq事物进行关联啊做关联的分析查询，还有还有就是具体执行的一些统计情况，我们可以从多个维度进行聚合啊查看。那么同时基于全链路的这个信息，那么我们是在对于我们的实时诊断功能方面也会有啊，新的信息的提供和深深度啊深度的提升。

那接下来我们详细介绍一下全链路分析这个功能。那么对让数据库更加容易运维呢，是业界不断都在努力的一个方向，那么要让呃做到智能化之前，那么我们必须要做到一个更仔细深入的洞察啊，那么我们我我们这个全链路分析的诉求呢？其实是啊，客户们由来已久的了，我们都都知道啊，我们想都想知道啊，每一条搜QL语句在系统当中是如何转发，如何执行的，那么如那么又如何将搜QL与业务进行关联，那么我们在数据库当中观察到的呃一条问题，SQL语句可以快速的对应上到底是哪一个业务啊，那么这条SQ语句的耗时情况啊是怎么样子的？那么再从统计的维度去看啊，SQL它的统计，事物的统计，以及以及关联业务的一个统计特征，那么这样能够更快速的查看出问题的根源。

那么基于此这个诉求，那么我们DB部是全面的接入了个审计日志，借助审计日志的详细信息，以及呃，我们呃，我们那个呃提供的一个业务标签功能，可以做到啊搜购的分析，事务的分析和业务流水的分析，帮助业务研发去做精准的优化，也让我们的呃数据库运维更加的轻松。那这里就不得不提到我们是如何将业务和circleq进行关联的。啊，这里我们提出了一种可观测的搜Q的一种方式，那么我们为一条搜QL语句加入一个标签，那所谓的标签就是咱们片子中看到的每条soql语句前面的一段注释，那这个注释的内容呢，是以一个key和value成对，多个key value对的方式能呈现出来，那这里的每个key value都是有业务含义的，用户可以自定义k value的含义，以及需要多少个k value啊，都是可以用户自定义的。那比如说我这里举的例子，那就是我这里的key是一个business，那也就是说我这条语句的business是等于配的时候，那这条语句是来自支付业务线的，那他的channel渠道是一个VISA的渠道，然后这一次交易的流水是一个啊，日志号是AF03，那么啊，这条这一个注释呢，就是就成为了这条SQL的的一个标签，那这个标签呢，会随着这个搜QL的执行进入到啊数据库运行的每一个环节呢，对于。

分布式数据库的话，会进入到它的每一个节点。那么就让我们的circleql成为一个可追踪可观测的circleq，那既然circleq已经可以追踪可观测了，那由搜Q组成的事物也就变成了一个可追踪和可观测的对象，那所以基于上述的我们的一个设计思，那么我们接管了数据库当中每一个节点所产生的审计日志，那么我们流失的去处理这个审计日志，可以根据审计日志当中的一些实续信息，能够获取整个数据库系统当中每一个节点它的搜后的执行情况，那么它的持续的一个执行情况，再根据呃事物的一些特征可以拆分出它的事务来，那么我们这里就完成了业务到搜Q的关联，到事务的关联，基于此类信息，我们最终可以呈现为用户，呈现出整个搜Q在数据库当中运行的一个top步情况，一个明细的情况，那么再从统计的维度，我们可以以实续的方式看到，嗯。

宏观上会看到一个整体的一个QPS，或者说某一个业务它的一个曲线，那么发现一个业务的抖动等等，那么我们还可以从数据库啊。进程的节点的维度去统计各个节点的一些啊执行的统计特征，发现是不是有节点性的啊，一些执行倾斜偏差等等，那还可以从时间的维度，我们可以将这些统计分析的信息与历史进行对照，发现一些呃，我们的一些列化的一个趋势的情况，或者说我们优化过后的一个优化效果。

那么除开上面的啊基于circle口的，基于事务的，那么我们更提出一种基于啊，更深入到流水业务流水维度的一个分析，那么我们举一个例子，那以信用还呃信用卡的还款为例，那么我们分成一个储蓄款扣扣款和信用卡还款，那么肯定是这两个事物来构成的，因为我们一般来说储蓄呃卡的信息肯定是在一个是单独的一个实例，而信用卡又是在另一个实例，那么所以整个完整的流水呢，其实我们就可以看到这里是出现了一个跨实力的啊一个状态，那么在啊呃业务层可能是通过一个业务的一个中间件去驱动和连接这种跨实力的那个流水，最终完成整个业务流水的一个操作，那本质上我们的数据库的智能运维，除了辅助数据库是要辅，最终是要辅就达成业务的成功的，所以基于咱们这个呃思路的话，我们更进一步的，其实是不仅能够做到对soq的全链度分析，还有可以做到对事务层的，然后。

然后。基于此，做到甚至做到一个跨实力的分析和跨跨机房的分析，真正帮就是说业务从流水上，从流水的角度完成整个链度的可观测。那我们对于我们的全年度分析啊，这里就做一个简要的总结，那么基于我们啊全链路分析这个功能，利用到的审计日志的优势，那么其实我们是获得了一个信息的优势，数据的力度会更细，精度也更高。那么我们基于详细的信息就可以做到多维的一个统计分析，然后啊事物的洞察，还有历史趋势的分析，那么最终我们其实是因为还关联上的业务可以去啊赋能业务啊，让做到业务流水的洞察，监督业务的使用，那么将问题解决在上线前，所以在数据库的运维上，我们在啊整个全内容分析，在问题发线阶段，那我们可以知道啊SQ与业务的关联，去就迅速的推动业务进行改造优化，那当问题已经出现过后啊，因为我们有详细的数据库的运行信息，那么在实践当中我们可以看到整体的排个排账时间，呃，有可能会缩到3倍以上啊，我们。

在实际的案例当中，异常定位从小时级啊降低到了分钟级，那么在更重要的一个维度，我们提升了问题的预防的能力，将整个风险左移。那么在我们的开发阶段，可以通过全链路分析的top circle啊的功能，将一些优化用在开发阶段，然后避免真正上线运维阶段出现啊，出现更进一步的问题。好，上述就是全链络分析咱们的一个功能的情况，那么接下来还是介绍一下DV部在实施诊断和健康巡检方面的一些功能，那这一板块刚才有提到，那么最核心的就是其前24小时的近实时的诊断建议啊，这个是我们的产品的核心，那用户通过这个诊断告警就可以感知到数据库的运行异常，然后再根据我们的分析功能，例如啊慢SQL分析，空间分析确诊问题的原因，那根据我们给到的优化建议，在在后最后通过呃我们的会话管理等执行变更操作，完成整个应急闭环，那这是就是我们这个功能的整个操作逻辑，然后另一个就是巡检报告，那一通过一个定时的常态化的啊巡检报告，我们啊，可以为数据库的健康情况进行存档，那么通过一些分析可以也可以预防一些问题的发生。

那关于实时诊断方面，我们啊，在线上有提供将近60余项的呃诊断能力。包括这里啊，我们也是在不断的迭代和验证新的优化能力，包括引入了一些机器学习的功能，那么我们涵盖的维度有性能的可靠，可维护性的可靠，可靠性方面和可用性方面的，那么最近我们是推出了全表扫描的诊断项，以及啊组建溢出的这么一个预警功能，大家也欢迎使用和体验。

那在这SQL优化建议方面，这里我们具体的提了一个例子出来，那针对于这条语句的话，我们是给到了增加一条索引的建议，那这里还会进一步的给到我们优化前的执行计划，优化后的以及一个效果对比的一个预估。对，那然后就是我们获得了啊，来自于DB的诊断和建议问题的啊，诊断还有问题诊断的一个优化建议过后，我们可以通过我们的实时会话去啊观测现在啊。现在的那个呃，线上的绘画的一个具体的情况，那么还可以通过条件Q的方式去指定性的去啊做一些应急处理将啊不需要的一些啊，灾害性的一些绘画给查杀。

那这个是我们的健康报告的一个详细的情况，我们的健康报告分成几个部分，首先是给到一些概览性的啊信息以及评分，能方便啊一眼全局的知道啊，现在我们整体数据库的健康情况，那么在我们的报告的后面只是每一个啊详细的一个健康明细的情况，包括我们的呃，性能的异常的top，可靠性的异常top，还有慢搜账号异常啊，表空间的一些啊异常，还有性能曲线等等，那这些数据都可以啊，明细导出成表格，然后。方便做二次开发。那所以在实时诊断与分析啊，巡检我们的应用场景呢，主要就是这三个通过啊实时诊断啊，我们不间断的去诊断出问题，然后告知到用户，然后用户啊得到这个问题提示过后，通过DBB的漫长分析，空间分析，三库优化等工具去解决这个问题，或者说是解决啊，或者说是优化我们的SQ，那另外一个就是健康的定期巡检啊，生成报告得到一个评分啊，我们可以关，可以对这个报告进行一个存档，然后可以做历史的一个数据库，健康的一个复盘。

和分析。那所以综上我们接下来归纳一下DB bring啊提供的这两大模块的一些使用经验的总结，那首先是在我们全内路分析这个场景下，我们通过呃，咱们可以通过DB泵提供的全链路分析功能呢，可以在业务切流的时候，呃观察整个呃各业务切流的全程的情况，就是感知整个切流的进展，那么对于往往我们是在新业务发布或者业务变更的时候，往往是数据库运维的啊高难度的时刻，那有了这个工具的呃帮助我们更能更胸有成竹的说是发现问题以及及及时的进行问题的处理。另一个就是异常的定位，那例如在主从切换的时候，我们可以迅速的根据b logo的信息反查到呃我们的审计日志啊对应的的具体搜后L语句，然后通过DV问的具体搜语句的啊，上下文已经啊，同会化上下文的帮您已经做好的这个关联，以及业务的关联啊，快速知道当时现场是一个什。

什么样的情况就是能够啊做到问题的异常定位和分析复盘，还有一个第三个方面就是在top circle的一个分析，那么我们可以在线上运维的时候获取一些呃，Top circle的一个情况去为我们的下一阶段的优化做准备，那么也可以是说在开发阶段去呃将这些top so问题给直接就处理掉，那这里只是简单的举了三个场景，实际的我们应用方式还会有非常多，例如对啊事物的分析，这里还没有列举出来。那所以综上我们再从dev develops的一个呃，整个研发流水的呃视角，我们来看对DBB的一些应用场景，那在代码的撰写阶段，我们可以通过SQL优化建议，直接给研发工程师给到最优的啊SQL撰写方式的建议啊，然后在研发啊功能完成过后进入测试阶段，那么这个时候可以关注DV泵的实时诊断告警，将这些告告警一一进行处理，那么可以说此时大的关于数据库方面的问题应该就不会有了。

那么可能我们此时阶段只是完成了功能OK，但是可能是在数据压力下，或者性能啊高并发的要求下，其实是不能满足我们的设计目标的，那么就要借助我们DB泵的全链路分析功能啊，我们可以在压测的时候是关注DB泵的全链路分析里边提供的统计分析的一些信息，来借助这种统计分析信息，我们找到高频circleql和慢SQL进入进行深入的优化。那最后就是上线运行，上线运行过后啊，我们其实就是关注DB的实时诊断的告警，有问题及时的发现和进行处理。那么同时也。

观察我们的全链路分析给出的一些曲线情况，发现一些性能的抖动啊，方便方便我们对啊问题有一个提前的预先的感知，以及说是根据全年的分析的，呃，搜口明细方便做到问题复盘的一个指引。啊，上面就是啊，今天对DBB的一个，呃，内容全链分析的一个分享啊，感谢各位的观看。也感谢何老师的精彩分享，嗯，如果有疑问的同学呢，也请您在问答区留言，我们的讲师啊会在问答环节为大家答疑解惑，接下来呢，让我们有请今天的第二位分享嘉宾来自腾讯云数据库高级开发工程师李淑斌。李老师作为腾讯云数据库代理业务的负责人，专注于生数据库开发多年，在数据库中间建领域有着丰富的经验，工作期间负责完成了腾讯云数据库代理业务的整体架构和功能设计，对于数据库代理中的读写分离、连接池、连接保持等功能有着深入的研究和大量的实践经验。

欢迎李老师带来云数据库my circle应用数据库代理的架构解析与最佳实践主题分享，有请。嗯，好的，嗯，谢谢主持人，嗯，大家好，我是腾讯数据库高级开发工程师李树兵啊，也是这个腾讯数据库MYSQL数据库代理这个功能的业务负责人。啊，那数据库代理这个业务呢。嗯，它是在二一年上线，到今天呢，也是两年多，最近呢，开始正式的进入这个商业化的这个流程啊，今天呢，我给大家也是带来这个数据库代理这个分享的内容，首先呢是我们为什么需要数据库代理，以及数据库代理的这个架构设计最佳时间，也就是说我们怎么用数据库代理。那好，我们先看一下为为什么我们需要数据库代理这个功能，那我们可以想象一下，如果我们没有数据库代理，我们只是申请一个数据库啊，最初的情况就是我们申请一个读写实例啊，有自己的规格，比如说我们44核8g啊，它也有一个连接地址，那这时候呢，我们工程师，研发工程师在去对这个数据库进行操作的时候，其实是相对简单的，比如说我们可以啊对这个数据库首先建联去执行语句，然后再返回。

这样呢，我们的研发工程师就已经可以把这个数据库用起来。但是我们也知道这个业务是在不断增长的，尤其像嗯，可能像互联网业务，它更多的是这种读多写少的业务，所以说当他读请求量不断增大的时候呢，我们会遇到这种。我们需要去申请一个新的只读实例这样一个场景，那比如说我们又申请一个四核8g的这样一个只读实例，它呢也有自己的这个，呃，连接地址。嗯，这是我们的工程师呢，可能需要对原来的这个查询函数做一些改造，对吧，我们可能需要为了使用这个指读实例呢，我们希望把更多的这个读请求发到这个指读值顶上去。

所以呢，那么这里可能需要对这个读写类型进行一下区分，并且呢，对，嗯，比如说我们判断这个是一个写语句，那就发到主持语上去啊，读语句呢，再发到这个数语上去，进行一些代码的改造，对吧？那这时候呢，嗯，看起来也还好，但是我们知道这个这个业务不可能永远这么简单，对吧？当我们随着这个业务的不断发展，就业务量不断增大，我们可能会申请更多的制度实力。啊，这时候呢，我们的需求会变得更加的复杂，比如说当这个第二个制度实例啊，它的规格我们申请了一个很大的对吧，有一个16G32G的一个一个大的制度实例，那我们申请这个大规格实例之后呢，我们想把更多的请求啊，发到这个新的指律是制度实例上去，然后呢，第二点呢，是当这个指读实例发生延迟或者宕机的时候呢，我们想把这个请求发到这个延迟更低的健康实例上去，因为我们知道这个。

在买SQ架构下，这个只读实力的延迟有时候是不可避免的，所以说我们希望在发生延迟的时候呢，还尽可能读到这个延迟低的数据，这个时候呢，就希望能把这个数据发到延迟低的这里上去。啊，然后还有就是刚才我们这个代码，不知道大家注没注意到，它有一个细节，就是说它是每次需要建联再去执行请求的，这样的话，嗯，MYSQL数据库的这个建联啊，它是会损耗比较多的这个CPU资源的，如果说呢，我们能实现一个连接池呢，就可以避免这个频繁建联的影响。然后第4点呢，就是说升级数据库会触发连接闪断，因为我们知道这个云音上的数据库啊，我们经常会面临一个情况，就是如果它的这个规格不够的时候，我们可能要升级，或者说他可能我们可能要做这个跨行区的迁移，这种时候呢，都会触发这个实力本身的这个重启，那这个实力重启操作呢，对业务上的体现就可能会不太好，它可能会造成业务上连接这种，嗯，暂时的短暂的不可用。

嗯，这时候呢，我们最好能希望这个业务不要感知到这个这个这个情况对吧？啊好，这个其实嗯，当然需求不光是这4条，我只是列了4条，这这点比较明确的需求就是其实这些都是我们用到数据库的时候。就实实在在的痛点，那为了解决这些呢，就是其实这么多中年，其实我们也一直有很多的这种解决方案去解决这些东西啊，假设我我们有很多的这种，呃，研发工程师团队，我们可以很好的解决这4条，对吧，那我们再来提一条要求，就是明天就要，那这样的话，我们这个工程师团队可能也就只能打问号了。啊，那我们来看一下，就归纳一下这些需求，首先呢，就是说我们数据库代理这个它要有很丰富的功能，像读写分离，负载均衡连接池这些啊这些功能呢，可能有很多，然后业务上呢，也也会根据自己的需求呢，去选择不同的功能，当然这些功能呢，我们其实嗯，我们数据库代理这个这个方向上啊，也有很多的这个开源的就是组件可以去实现这些功能。

但是呢，我们说在云上使用数据库呢，跟这种单机版的，就是我们之前使用数据库的方式可能不太一样，因为云上使用数据库呢，我们更多的操作有一些云上的操作，比如说像刚才说的升降配，呃，这种迁移，它呢是有很多运维操作在里面，如果说我们在云上的做数据库代理呢，其实是跟之前的单机版的数据库代理不太一样的，因为我们可以支持这种云上的就是数据库的透明切换，做去做这种骨感的声量配，这个呢，需要整个的数据库代理的管控层面，内核层面和后面的数据库去做这种无缝的这种融合才能做到这一点，就是说它可以支持这个整个数据库集群的高可用。那第3点呢，就是开箱即用，这个很好理解，就是呃，数据库代理申请之后呢，它不需业务做任何的适配改造，就是我我们刚才说的那些代码逻辑可以全部的省略掉啊，只需要连接数据库代理的这个连接地址，就可以享受所有的这个服务了。

好，那我们来看这个数据库代理的架构是指一个什么样的价格？嗯，最上面呢是这个VPC就是，呃，用户访问数据库代理呢，需要先走一个VPCVC呢先会申请一个VC的地址，这个地址呢，可以是跟主实力独立在主持力之外的一个地址。啊，当连接这个地址之后呢。啊，VC会把连接分发给下面的节点啊，也是数据库代理的节点。数据库代理的节点呢，可能有很多个啊，我们这里面画了两个，是为了试示例一下啊，可以我们也可以申请多个数据库代理节点。然后数据库代理节点呢，再往下就是我们的真正的数据库层啊，数据库呢，我们这里看到我们刚才例子里面这里一个一主两层的一个数据库的一个架构。

啊，这就是我们简单的一个数据库代理的架构设计。啊，那我们现在来看一下，就是刚才说的可能比较抽象，因为架构图看起来可能没有那么实际啊，我们现再来，现在就是来看一下这个更直观一些的，就是我们在控制台去对一个数据库实例，开通了数据库代理之后，我们就会来到这么一个界面。啊，这样一个界面呢，首先我们看到这边有基本信息，这边有在基本信息下面有连接地址的信息，啊，我们先来看这个地方，这里里面有一个数据库代理的版本。啊，这里面有一个升级内核小标本，如果我们点进去的话，会进入到这个界面。这个界面里面呢，我们可以选择就是当前数据库的版本啊，当然这个不光是说你你这个去去点击这个升级啊，就是我们在创建实例的时候，也是需要去选择这个版本的。呃，我数据库代理的版本呢，分为，嗯，可以认为分为两个版本啊，一个是稳定版，一个是尝鲜版啊。稳定版呢是提供一些基础功能，比如像读写分离啊，这里面虽然我们说的是基础功能，但实际上现在稳定版已经是功能比较丰富了。

推荐呢，就是如果说我们就是看到这个稳定版的这些功能，就是前期调研发现稳定版的功能已经满足我们的这个日常的需求了，那可能我们就直接使用稳定版就可以了。那长线版呢，它是支持更多的高级特性，比如说像15级连夜池啊这些呢，都是一些我们的这个这个高级功能，但是高级功能呢，可能会有一些这个需要业务去做这种这个。怎么说这个兼容性的风险评估吧，这个所以说更推荐这个有特性的需求，比如说我就需要，嗯，有我这个收集连接池，它能那个大幅度的降低你前面的连接使用数，如果说有这种特性的需求，那我们可以去使用这个长线板，去用我们这个特定的高级功能。啊好，我们再回来，回来的这个页面，我们可以看到这个下面有一个节点个数，我们可以在这里调整配置。

点击这个按钮呢，我们可以看到这个，这里面就是一个proceed的规格的配置。啊，首先是有一个代理的规格，最上面这个代理的规格呢，它写的是呃，有几何几几G的内存，这个呢，就是我们所有的节点，我们的每个proc节点都是同样规格的，就是说都是上面写的这个规格。嗯，再往下呢，我们可以看到有可用区的设置，我们可以在不同的可用区里面申请不同数量的啊代理节点。那这里面就很有意思啊，就是我们，嗯，看到这个可用区，我们可以会可以联想到，就是我们后面的数据库，其实是可以申请，呃，主库和只读库在不同的可能区的。比如说像我们这样架构图。对于这种跨可能区的实力，我们先看最下面这一层，最下面这一层的跨可能区的实例，它在比如说这个这边蓝色的是广州一区啊，它在广州一区呢，有一个主实力和一个制度实例。

在广州二区呢，有一个直流实力。啊，我们这样呢，我们正常访问的这个时候呢，可能就是就是如果说不经过数据库代理呢，可能要就是你访问这这种跨区的。就是访问如果跨跨城区了的话，可能造成这个请求会是这个延迟会增加的比较多，那通过这个数据库代理这种跨城区的架构呢，我们再可以再从上面再看一下啊，如果是一个广州一区的CBM呢，它发送请求到这个BPC的时候，我们的VPC会做一个就近访问的操作。他会把请求优先发到这个。这个广州一区的数据库代理上，那广州一区的数据库代理呢，它后面连接的是广州一区的主库和制度库。那同样广州二区走这个链下来呢，它会优先发到广州二区的这个制度事宜，当然这个写请求没有办法，因为我们只有一个主实力嘛，所以说写请求可能还是要发到主播上去，但是呢，我们的读请求就可以就近的发到对应的可能区上，然后从而实现这种读请求的跨控区访问。

啊，这个是我们的跨孔区的设计。然后回到这个页面，我们再可以看下面啊，下面我们这个是就数据库代理是支持多个连接地址的啊，我们可以在这里点击这个新增访问地址。嗯，新增访问地址，我们可以看到这个每个连接地址还有自己独立的这个属性配置，首先就是它是不是读写分离的，还是只读的，还有各种各样的这个配置，这个我们后面会提到，就是包括它下面挂哪几个啊实例，然后哪几个实例分别的权重是多少。啊，点击确定之后呢，我们就会有一个新的地址啊，从架构图上看就是这样的，比如说啊，我们原来在读写地址已经有一个读写地址的基础上，我们新增了一个只读的地址啊，它是一个全新的VGC的一个地址。

那原来读写地址访问到呃，数据库代理的时候，分别访问到不同的数据库代理节点，数据库代理会根据比如说当前啊，我知道我访问的是通过读写地址访问的，那么我们会把请求分发给下面读写实例啊，和其他的制度节点做一个读写分离的操作，对吧。嗯，那如果是从只读地址进来的呢。只读地址，嗯，访问到PRO的时候。那我们会根据他访问地址的不同，我们识别到啊，这是一个只读地址的请求，那我们就只会把请求发到后面的主只读实例上去。啊，这样的话我们就可以实现一套PRO集群，就可以是在上面添加多个地址，然后实现多个业务的共同访问。啊好，我们再回到这个页面。这里面呢，我们可以看到每个这个。呃，连接地址它可都可以去独立的去调整这个配置，点击这个调整配置按钮呢，我们可以进到这个页面。

嗯，这个页面里面，嗯，包含了我们这里面的大多大多数功能，就是嗯，我们现在有的，比如像这个读写分离，负载均衡延迟剔除最小保留数啊这些，当然这些功能由于这个时间关系啊，今天不会在这里继续展开来讲啊，今天主要是这个这个，如果说大家对这个功能具体有兴趣的话，可以去看我们这个官网的技术文档，里面有更详细的解释。啊，对于这些功能呢，每一个功能都是可以分别的在不同的连接地址里面去设啊，比如说我们这个这个读写分离和负载均衡，我们就在这里面分别的去调整它的权重，然后包括这个这个其他的一些功能都是在这里面去进行这个配置的。那最后呢，就是我们这个性能监控，这个性能监控呢，就是我们数据库，它里有一个自己的监控界面，我们可以在这里面看到每一个啊，每一个proc节点，就是数据和代理的节点的分别不同的这个性能监控指标，嗯，比较值得关注的就是这个CPU使用率和内存使用率，因为这个的话跟我们这个。

呃，具体的业务可能会有关系，比如说我们的业务是这种，嗯，QPS很高，嗯，但是每个请求呢没有那么大，然后请求呢，就是返回的也比较快，这时候呢，他可能会对这个CPU使用率会是它的瓶颈，所以我们可能更多的要关注这个CPU的指标。那如果说我们的请求都是这种很大的色很大的查询，它的结果集也很大。那这个时候呢，可就可能会造成这个内存使用率就会偏高，那我们这时候呢，就要关注这个内存的使用率去呃调节我们的后续业务的请求，比如说比如说我们的CPU就是估计快打满了，好对这个我们也是接入了这个云监控系统了，所以说我们可以就在云监控上设一个那个告警，当CPU达到多少的时候，可能我们就需要去调节，刚才我们说调节proc的这个数据库代理的规格啊，能让它承载更大的星球。

那好啊，那今天呢，我们的分享就到这里啊，也感谢大家观看。感谢李老师的精彩分享，嗯，那如果我们有疑问的同学啊，也请您在问答区进行留言，我们的讲师会在问答环节为大家答疑解惑。好了，那接下来有请今天的最后一位分享嘉宾，来自腾讯云数据库高级产品经理陈昌明老师，陈老师呢是腾讯云数据库my circleql产品线的负责人，在高可用解决方案、信息安全、系统规化、性能优化、灾难恢复与信息系统整合方面拥有着丰富的实战经验，曾经为网络运营商、银行、能源行业例如国网、南网以及政府等各行业的关键业务系统提供运维升级、项目实施与管理、容灾建设等疑难咨询与技术实施服务。

欢迎陈老师给我们带来向着云原生进化新架构下的腾讯云数据库my circle主题分享，有请。呃，感谢主持人，然后感谢前面两位老师的分享，然后接下来我将给大家分享向着原生进化新架构下的腾讯云数据库MYSQL这样一个主题。我们会分为三个部分，然后来给大家介绍一下我们这次分享的一个内容，第一个为什么我们需要新架构，然后第二部分是我们基于新架构所产生的新的形态，然后以第三个在这样的新形态下面，我们未来会朝着怎么样一个方向发展。第一个为什么我们需要新架构，就是在传统的企业里面，包括传统的IDC部署里面，然后大多数的数据库采用的是纯船一体的这样一个架构，包括我们存量的啊，就是现有的一些高可用的架构的话，也是采用纯酸一体这样的架构的，然后在纯酸一体这样的架构下呢，然后有一个。

呃，很大的限制就是你的计算资源和存储资源没有办法做到分离，然后你的计算资源和存储资源它的规格就会绑定。比如说你需要一个。很小的计算规格去匹配一个比较大的存储，那很有可能导致在存算一体这种架构下，然后会导致你的计算资源过多的浪费，然后并没有被使用上，然后它会出现一个错配的情况。然后并且在由于。存算一体化的架构，存储资源和计算资源是在一体的，它没有办法做到。快速的。啊，快速的存储的。故障重建，然后你的计算的故障重建，然后它是必须在一起的，然后所以这种情况下，大多数在这种情况下买这买这个的话会采用一个啊主从的一个架构，然后去保障并且重击，为了保障它不出现问题，然后尽可能少出现问题和风险。

然后是把它做隐藏的，就这样的话，用户是付出了呃更多的成本，然后去保障了你的可能性，但是更多的这成本所带来的呃，计算资源和存储资源的消耗呢，并没有被业务所使用到，那存在这样一个问题。但是存在一体化价格呢，也带来也带来了非常好的一个性能表现，因为它使用的是本地的存储资源，然后并不通过网络或其他的方式来增加自己的请求的开销，那他拥有极低的一个IO响应时间，那基本上都在纳秒级别。然后本地资源如果在具备情况下，也可以去实现无损的一个啊扩缩容，然后比如说本地的本地的CPU的呃扩容，或者说内存的扩容，然后都可以做到，并且基于存在一体，这样价格的话，整个网络的拓扑结构是非常的简单的。但是随着用户的数据的增长，然后以及不同业务对计算资源和存储资源的需求的。变化。同时。

现在原生整个架构在向前布局过程当中，它的整个调度啊，然后他所提供的极限的能力啊，包括它的灾难恢复的能力的增强，我们也不得不去向着这一个架构，然后去进行演进。然后在这样一个架构下，我们通过使用了。呃，腾讯云所提供的啊，底层容器化服务，然后去构建了这样一个买赛克的服务，然后我们依然去通过云盘，然后去给他提供底层的。呃，存储能力，并且当出现单点的计算资源故障时，而我们会优先通过。优先优先通过云原生的方式，然后来将它的计算能力，然后去恢复，然后可以实现啊分钟级的故障治愈。然后如果在这种情况下依然提供了。呃，只读实例，然后给大家用作备库和只读的一个请求的。

请求能力的一个分发，然后去实现。计算能力的一个横向的扩展。并且我们的重库和。存算一体架构有个很大的区别，我们依然提供给用户访问的能力，由于它本身具备存算分离这样架构下一个治愈的能力，所以我们并不担心。由于啊。重节点或者说只读节点，然后在使用过程当中出现了异常而导致说你的节点故障会无法恢复啊，我们依然能保证，保证这样的一个恢复了SLV的一个承诺。然后并且在使用了快照这样一个备份的方式的时候，我们能做到非常快速的一个恢复，我们现在是每15分钟，然后就会进行一个增量快照的。创建，然后去保障你的恢复时间。就哪怕出现灾难性的问题，然后也要做到15分钟之内，然后进行一个恢复。

但是在这样一个原始的架构下。其实大多数的。呃，用户包括在自建的过程当中，然后都会用到原生。的这样一个架构来构建买服务，但在这样的一个背景和架构下的话，也会有很多这个架构所带来的问题，那我们去采取了很多的技术手段，然后来避免这样的一个问题发生，那今天也给大家分享一下我们是怎么解决这些问题的。那比如说我们在。做主重切换，或者说啊做一些节点重构的情况下。那这个时候，呃，我需要快速的把我的热点数据，然后加载到内存当中，而不是通过靠业务访问的方式，然后被动的然后加载热点数据来提升它的一个响应时间，那我们就开发出了一个发发库预热的一个能力。那当我的节点重建，然后或者是常态化的一个迁移变配。

啊，一一或者是出现故障切换的时候，我都需要把我当前的热点的读写的。把客户的信息，然后快速的给他预热起来，而不是靠呃业务被动的然后去进行预热，那在这种情况下的话，我们就可以做到。再分在秒级，然后将我们的内内存的热点数据，然后加那个磁盘上的热点数据，然后加载到内存当中，然后让服务在一秒钟之内就恢复正常，如果我们采用的是被动被动响应的方式的话，那整个性能的恢复时长大概需要30~60秒，那在这个时间点的话，对于很多。交易型的业务来说，他就是无法忍受的，然后带来了很多这种性能的问题。然后并且我们也通过组成缓存同步的方式去解决了读写热点以及只读热点之间的差异的GAP的问题。因为对于。专用于读写的节点和只读的节点。它的。

包法库所缓存的数据，热点数据是不太相同的，那通过我们组成缓存同步的一个能力，当你的重库，你的只读节点，然后切换为读写模式的时候，它可以快速的预热作为一个读写节点，它应该预热的那份数据来加强。来加快。用户业务性能恢复的一个效率，那也是做到一个秒级。然后在使用存算分离这样一个价格的时候，和本地盘有一个最大的区别，就是刚才所说的就是本地盘它的请，它的IO请求都是那么级别的。但是在。使用存在分离这样价格的情况下通过网络去访问。实际上它的。整个IO的请求是没有办法做到纳秒级别。并且它的整个存储带宽跟你的磁盘购买量，然后是有关系的。那这个时候就出现一个很明显需要去解决的问题，就是如何我在保证数据库安全的情况下。

然后数据一致性的情况下，去尽量减少我的IO请求，那比如说MYSQL的inno DB有一个。然后有个机制叫W。然后它是为了避免而操作系统写入磁盘的时候没有办法保证16K原子的写入的方式，然而导致的页面分裂。然后而实现的一个能力，那这个的能力会导致你的数据会写两次，有两次IO操作，那就那就会导致你的IIO的消耗啊double。那我们通过16K原子写的能力，我们通过操作系统本身。然后来保障16K原子啊，16K写入以后是原子化的，就成功的话，就一定是完整的落盘，如果没有成功的话，那那就重新重新再重新写入就好了。那不需要去通过写两次的方式，然后去多占一份IO，然后去导致整整体的性能的下降，那首先带宽的问题，然后就解决了。

还有原子写的话，这个呢，你主要是通过文件系统CW就copy p外，然后这样一个异地更新的一个异步更新的一个机制，然后去确保my sol16K的原子写的整个写入的过程当中，然后是能够保障它是原子化的。然后从而减少了写入的一个开销，因为我们可以关闭W去保障你的。呃，页面写入的这样一个一致性。然后从最终的测试结果来看，然后原子写这个能力，在止血的这样一个场景下，然后普遍有30%~50%的一个提升。然后，并且在与存算分离这样一个架构下面，因为我的整体的通道的写入量减少了，我可以让步一部分写入的IO。分配给读请求，那这个时候我们在读写场景下，依然能够有将近15%的一个提升。

除了以上呃，原子写的内核能力，包括我们的buffer BP, 就是buffer铺的预热这样能力以外，我们在操作系统以及内核测也做了很多的优化，比如说我们的代码端锁定以及多备份，然后ORC的on window, 然后网络配置的优化，然后内核占用的内存优化，然后nova Vs SP诺克相关的优化，然后通通的优化给我们带来了差不多15%的性能提升。这张图就代表了我们在优化前以及优化后。然后能够。体现的一个性能的差异。我们对比原有的一个。呃，测试的结果啊，首先我先说明一下我们测试的方式，我们使用的是C，然后再读写混合这样一个场景，然后并发度设定为我们所。购买的。

计算规格的8倍的那个。并发度，然后来进行测试，比如说你购买的四个，那现在它的并发度就32，然后这种方式来进行一个测试和验证的，那在磁盘的大小不变的，我们的数据量不变，然后测试方法不变的情况下，那我们在优化前优化后的性能差异会达到30%~50%。然后目前大家也可以通过官网，然后去进行一个政策的申请，然后可以啊去使用这样一个集讯版的一个能力，也就完全是基于我们原生存在分离这样架构构建的一个云输入马SQL。然后在这个新的架构下，还支持一些原来纯算那个纯算一体的这样一个架构，不支持的点，其实刚才有说过，就我们支持重新只读，我们可以通过快照的方式快速去增加节点，并不需要通过你完整的备份，然后去再做恢复，然后这样一个很漫长的过程，包括你的整个配置变更的过程，然后都会非常的快速。

然后从原来的小时级别，然后下降到分众级别。然后，并且我们提供了其中每个节点的监控信息，告警信息，然后可以让用户去进行一个配置，然后去查看对应的监控，然后以满足业务的一个诉求。最后在这样一个存在分离架构下面，那么我们会朝着哪些方向去演进呢？其实不管是啊用户在自建也好，还是说我们本身去构建也好，然后都可以提供给大家参考啊，可以看一下就第一个的话。就是Q1目前已经上线了，然后目前在种植阶段，在Q2的话，我们预计是会提供给啊用户一键一键升级中，从纯算存算一体化的这样架构，然后升级到集群板这样一个存算分离架构的一个能力，然后并且也支持独立的一个只读实例，就是这一个只读实例的话，不参与主从切换，它是独立存在的，然后并且可以通过PRO来进行一个读写分离，像刚才啊书斌老师所分享的一样啊，依然可以支持PRO的读写分离，然后权重包括10物级连接池等等能力。

然后通过这样的能力支持的话，然后去再加上它快速的横向扩展，只读实力这样一个能力啊，然后可以使得它的读请求的承载的能力，能够快速的横向去进行扩展。然后在未来的话，还会支持数据备份，高频备份以及备份下载啊等等的能力，在高可用以及数据完整性上，然后提供完整的支持。然后直到最后的话，在用了分析这架构好，所有人都会朝着一个目标引进，就是。就我我希望我所有的云上的产品都是啊，开箱即用，然后。按按量付费，按照我的使用，然后去进行付费，而不是说我需要特定的，然后买一个特定的规格，然后在那个呃地方，并且我的存储也一样，除了计算资源我需要做到按量以外，那我的存储也希望能够做到自动管理，然后做到按量去那所有的云原生，或者说。

啊，云上的这个目标都是资源的。啊，极致的灵活的使用，那我们会也会朝着这个方向去不断的前进啊。那谢谢大家，我的分享就到这里。谢谢，感谢感谢老师，陈老师给我们带来的精彩分享，好了，那接下来呢，我们就将进入今天的QA环节，请三位老师来为我们解答问题，嗯，我们收集了一下观众们提出的问题啊，那首先呢，呃，第一个问题是呃给到李老师的，嗯，问数据库代理如何保证只读节点的负载均衡，有请李老师。嗯，哎，大家好，嗯。我刚才这个问题其实问的是数据库代理的，就是负载均衡是如何实现的，相当于啊，数据库代理对于只读实力呢，其实嗯，你就像我刚才分享时候说过的，就是它下面可能挂载多个制度实例啊，多个制度实例呢，之间会就是数据库，它也会同时跟多个制度实力分别建连，也就是说我们的这个负载均衡的力度啊，它是不是连接力度的，是这个请求为力度的，也就说我们的负载均衡能做到更细的力度，然后呢，我们现在采取的一个算法呢，是叫加权轮询，是一个相对静态的算法，然后后期呢，我们也会上线这个更加智能的，就叫动态负载均衡，自适应负载均衡这样的算法，嗯，等上线之后呢，大家也可以去了解一下，嗯。

好的，嗯，那我们观众朋友还想了解一下数据库代理是如何保证高可用的。哦，对，高可用这里其实是哦，我们数据库代理的高可用分为两个部分，一第一个部分呢，就是说刚才我们分享里提到了，它可以保证后面的数据库代理，呃，数据库的节点啊的高可用，比如说它可以可以保证后面的数据库节点在迁移的过程中呢，我们的数据库代理可以保证这个前端连接不断开啊另一方面的高可用呢，数据数据库节点本身的高可用，这点的高可用呢，我们可以看到，就是刚才我们架构图里也看到，嗯，Proc节点就是数据库的节点呢，通常都是有两个以上啊，只要通过这个，因为数据库代理节点本身是没有状态的，任何一个节点呢，出现宕机呢，其他的节点都可以承载它的这个，就剩余的节点都可以承载他的请求。

所以说呢，我们可以用这种多节点的方式来保证这种高可用。好的，谢谢，那第三个问题还是给到李老师啊，说老师您好，如果我们的主实力开启了SSL加密传输业务，这里如果使用了代理作为连接，那是否SSL就不支持了呢？嗯，这个SSL也在我们的今年的规划里啊，现在暂时可能还是没有这个支持SSL，但是SSL已经在这个提上日程了，已经大家可以期待一下后续的功能，嗯，好的好的，嗯，那下一个问题代理的防闪断能力是否可以理解成以后升级切换都不用再担心闪断导致连接不上的问题了呢？

对，是的，这个呃，房产段主要就是为了解决这个切换时候会有中间会有一段时间这个连接不可用的时候，这个其实是一个很常见的一个痛点，这个数据库代理在这里面的做法呢，就是说嗯，在切换发生的时候，我我据库代理会承载，就是就相当于是客户发的请求呢，会暂时的没有响应，但是连接不会断开，等到新的实例就是升级时，升级成功之后，新的实例拉起来恢复之后，我们会把这个数据库代理这块。就相当于是缓存的请求啊，再发到新的节点上去，重新建立这个连接，这样呢就是对于客户端来说，他感受就是说卡了一下，然后之后就链接就恢复了，而不像不会像过去一样，就是会在断联期间疯狂报错。好的好的，那接下来下一个问题还是有请李老师啊，我们在使用代理的时候，给主实力只读实例设置权重，这里可以怎么理解呢？也就是之前看文档啊没有很啊没有很看明白，嗯，没看对，是的，这个权重呢，其实我们说的权重是指的读权重，因为我们说读写分离嘛，啊读写分离，读读请求，我们可以去做这个负载均衡，但是写请求的话，我们可能是一定要录由到这个主释义上去的。

那比如说哦，我们可以设想这样一个场景啊，就是嗯，下面有一主一从，他们权重是1:1，然后这个时候呢，我们来了5条这个写请求，还有10条读请求，这个时候呢，5条写请求全都会发到主持力上去，这里面呢是不会计计算这个负载均衡的，那剩下10条的这个读请求呢，会按照加权轮询的方式，呃，依次的发到这个主实力和指度实力上，保证这个独独请求的这个分配是1:1这样。好的，那那李老师的最后一个问题，呃，问我们数据库代理的配置有没有什么标准选择，有没有什么标准。嗯，是的，我们数据库代理，嗯在官网上其实也有一个就是经验的配置，就是说我们后面DB的这个，呃，核数它的总合数加一起，比如说我们主部加主度实力，呃主织加主流实力，它总的合数是64啊，有两个32的和的，那它再除以8，就是我们推荐的数据库代理的总和数，但是这个呢，更多是的是推出一个经验的这个值，而每个用户的业务呢，可能都不太一样，比如说像我刚才说的，有的呢可能是说会耗用更多的CPU资源，有的可能耗用更多的内存资源，这个可能要根据大家的业务类型，然后具体的就是可以一开始申请一个大一点的规格的代理实例，之后呢，我们再可以酌情的再去调整。

好的好的，感谢感谢老师给我们的详尽的解答，嗯，谢谢李老师啊，那下面呢，观众的问题是给到我们的何老师的，首先第一个问题是我们的DB brain对于MY集群版支持了吗？

啊好的啊，主持人好，就是现在DB不呢，对MYSQL集训版的支持规划是在6月底会完成第一个版本的发布啊，我们我们目前对MYSO后主重版的支持是最全面的啊，大概是这个情况。好的，我们线上同学还想了解一下，那对于全链分析的功能线是怎么样的。呃，全年的分析呢，我们目前是在私有上市得到了充分的应用，在客户场景当中有了大量的部署和使用，然后近期是在公有云上线了第一个版本能够看到，呃，我们的一个全能的明细板块，还有一个搜Q统计分析板块，那接下来会逐步的上线我们已经成熟的事物的分析，还有呃业务分析等等的这一块的功能都会陆陆续续的上线，那随着这些功能的啊上线，那么我们是在对事物的实时诊断方面，也会有更多的明细信息能够呈现出来啊，谢谢，谢谢主持。嗯，好的，那我们下一个问题是DB brain的收费方式是什么样的？

呃，DB部目前暂时还没有收费啊，就是在诊断部分是完全免费给大家的使用，然后在呃全链路分析部分呢，也是限时免费的一个状态，未来如果有收费商业化的呃，规划肯定会提前的通知到各位客户老师。好的，那我们朋友问到您好老师，我们的业务运维非常的依赖DB，那现在就是感觉在产品的控制台上不太好直接进入到DB brain这里，我们有没有一些优化计划呢？嗯，好的，就是其实我们和每个呃就是数据库产品，例如呃，My circle, 还有就是red mango在控制台上呢，都有一些呃交互的地方，可以啊加强这种双向的联系，那可能我们接下来既然啊有这种老师有这种反馈的话，我们会进一步梳理是是否这种呃连接的位置啊，是否更加的合理，更加的方便那。去做进一步的优化啊，感谢那位老师的一个建议啊。

好，那最后一个问题，呃，是想问一下DB brain的审计分析和数据库审计之间啊，这二者是什么关系？这里DB brain的审计分析呢，是不是基于数据库审计的，那我们是不是就开启数据库审计就能够使用全链路分析了？啊，数据库审计呢，是由各个数据库产品提供的一个基础，呃，审计日志空啊审计日志的功能，但它主要的目标是满足一些安全合规的诉求，或者说是有一些呃，企业内想要做的一些存档分析内的诉求啊，那么是这么一个视角，那在DB部分这边呢，只是说是利用了审计日志这一种数据源去做分析，所以其实啊，DB部分提供的是一个分析的服务，嗯，所以是还是说是两类不太一样的一种服务方式啊，那么TPP的权利的分析呢，有啊，重点是基于审计日志，那接下来我们还会基于错误日志，那管控日志等等的综合的数据进行啊分析，所以在我们这边呢，是叫做一个全链容分析啊这么一个啊，功能相对还是比较有差异的啊，谢谢。

好的好的啊，那我们这边再再还有一个问题给娜老师，嗯，是引入数据库的代理对于读写性能的影响是什么样的。啊，这个问题请请我们的老师来帮我们，嗯，请书斌老师来帮我们回答一下，嗯，可以再重复一下吗？这个问题是问到引入数据库代理对于读写性能的影响是什么样的？嗯，对对于读一体性能影响这里，嗯，这个里我还是推荐就是大家对自己的业务可以先尝试压测一下，因为数据库代理现在来看，就是我们从实际体验上对于性能的影响还是比较小的，这个主要主要的影响呢，就是嗯，比如说我们的思考就是就是这种可能耗时时间比较久的，那主要时间呢，就是主要耗时都在执行上了，那数据库代理对这种情况的这个业务呢，就是可以说是这个损耗时微乎其微的，就是你可能看不出来什么太大差异。

那如果我们这个磁扣非常快啊，执行的时间呢非常少，那这时候更多的时间占比会站在这个网络损耗上啊，那我们都知道数据库代理它毕竟属于一个中间线，就是这个网络损耗是没办法避免的，如果说这个我们的这个请求真的都非常非常快的话，那网络损耗就占上大头了，那这时候可能会有一些就是稍微明显的损耗啊，这时候就需要我们根据业务自己去评估了，嗯。好的好的，那再一次感谢三位老师给我们带来详细的解答，好的，那我们本次问答环节呢，也到此结束了，嗯，再一次感谢我们三位老师今天给我们带来的精彩分享，我们的时间过得很快，本次的课程也进入到了尾声，再一次感谢大家的参与与关注，再见。