深度技术揭秘 | 大促狂欢背后，如何有效评估并规划数据库计算资源？

对于一个数据库开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《深度技术揭秘 | 大促狂欢背后，如何有效评估并规划数据库计算资源？》，主要介绍了MySQL、算法、安全、关系型数据库，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

简介：经过“双11”、“618”这类互联网促销活动的验证，越来越多的互联网公司采用不定期营销活动来刺激消费，达到提升营收能力的目标。然而，在每一次业务狂欢的背后，如何科学地为促销活动准备相应的计算资源就变成了困扰开发人员的常态问题。此外，据Gartner统计，在疫情的影响下越来越多的企业开始加速关键业务模块从本地云往公有云上迁移，以提升企业服务的稳定性和容灾能力。如何有效评估并规划计算能力、计算引擎、带宽等关键资源的容量成为了云场景下的一项技术挑战。

1. 背景

经过“双11”、“618”这类互联网促销活动的验证，越来越多的互联网公司采用不定期营销活动来刺激消费，达到提升营收能力的目标。然而，在每一次业务狂欢的背后，如何科学地为促销活动准备相应的计算资源就变成了困扰开发人员的常态问题。此外，据Gartner统计，在疫情的影响下越来越多的企业开始加速关键业务模块从本地云往公有云上迁移，以提升企业服务的稳定性和容灾能力。如何有效评估并规划计算能力、计算引擎、带宽等关键资源的容量成为了云场景下的一项技术挑战。

针对这个场景，阿里云数据库自治服务团队（DAS）推出了智能压测服务，致力于解决大促场景下计算资源评估问题、迁移上云的离线资源容量规划、跨引擎迁移等数据库选型评估问题。DAS（Database Autonomy Service）是一种基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务，帮助用户消除数据库管理的复杂性及人工操作引发的服务故障，有效保障数据库服务的稳定、安全及高效，解决方案架构见图1。

2. 智能压测的组成

压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。一般针对网络服务器测试从传统的意义来讲是对网络服务器不断施加“压力”的测试，是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。在数据库场景下，压测通常指的是对数据库的性能进行测试，通过对数据库服务器不断提高执行SQL的数量和并发度，来测试既定规格下的数据库是否可以持续稳定地对外提供服务，并基于测试结果做出相应的决策，包括调整数据库规格、部署形态、业务SQL优化等等。通常情况下，完成一次压测主要涉及到三个关键部分：压测数据准备、流量回放和结果分析，如图2所示。

图2 智能压测的关键组成

压测数据：在数据库场景下，流量数据为SQL语句，但仅有执行时SQL语句是不够的。SQL语句在数据库内的执行过程中，真实数据分布和库表索引都会影响其执行时间。因此，数据库场景下，压测数据包含了数据库的库表结构、库表内数据、索引和SQL执行语句。此外，在一些有严格安全要求的特殊场景下，仅表结构允许复用，而具体原始数据不能被用于流量压测。针对这种情况，我们提出了智能生成数据的算法，产出符合原始数据分布的模拟数据用于回放。

流量回放技术：传统性能压测过程中，由于未对SQL执行语句按照原始流量的并发情况和执行次序做限制，出现压测与原始业务流量效果差异较大的现象，导致单次数据库资源评估任务中通常会进行多次压测，然后对性能结果数据求平均后再评估资源。这种方法需要耗费大量的测试时间，并且需要测试人员具有一定的数据库经验，通常需要DBA进行操作。针对这一问题，DAS对单次压测进行技术改进，通过压测幂等技术确保压测回放后的性能表现与原始业务流量性能相近，且无须多次回放，大幅节省了资源评估的时间并降低了对数据库压测经验的要求。

压测结果分析：有效的结果分析可以帮助用户合理的选择资源规格，并发现业务流量回放过程中存在的隐患。数据库的关键性能参数、关键性能指标的对比、SQL优化建议等数据可帮助用户理解资源差异和潜在优化点，辅助做出后续决策。

3. 智能压测技术内幕

3.1. 智能数据生成技术

关于数据库性能压测，业界存在很多开源的工具，例如Sysbench、mysqlslap、tpcc等。这类工具均可以通过并发大量数据库连接结合一定的查询语句来制造出一定的SQL流量，达到模拟业务高强度使用数据库的效果。但模拟场景下的性能表现通常和业务实际性能表现相差较大，故模拟压测不能满足计算资源评估的要求。利用业务数据库中的真实数据进行压测成为资源评估的基本条件。针对阿里云数据库用户，可通过SQL审计功能，方便的获取压测所需要的数据。而对于云下或阿里云ECS自建数据库的用户，较难获取历史上的库表数据或流量数据来做压测，甚至在一些有严格安全数据要求的场景下，连原始数据和SQL流量数据都是不被允许使用的。

目前，我们在单表查询场景下采用智能数据生成技术来产出符合业务数据分布的数据，可用于压测并评估资源。这个算法的前提是，需要我们已知一些SQL模版，以及这些SQL模版对应的执行指标，如RT，rows\_sent，rows\_affected等，我们希望实例化这些SQL模版来生成SQL，使得这些SQL在目标库表上执行时能得到相似的执行指标（这里我们假设同一模版的SQL都会以相同的执行计划来执行）。如图3所示，我们需要搜索相应的参数a和b来实例化这条SQL模版，使得在给定数据执行时返回行数为1。

图3 SQL模板

在搜索SQL参数的时候，对于点查询/点更新，可以直接利用主键和唯一键来做参数搜索。而对于返回行数/更新行数大于1行的情况，我们使用基于采样的基数估计方法来估计实例化后SQL的返回/更新行数，进而进行SQL模版实例化的参数搜索。

图4是我们对于钉钉一个读写业务在早高峰期的流量生成压测，可以看到流量生成压测和真实业务在多个指标上都有相似的表现，证明生成的数据可以有效的模拟线上真实数据。

图4 基于生成数据的压测效果

3.2. 压测幂等技术

在数据准备完成之后，如何有效且可重复的进行流量回放是智能压测中的另一项核心技术。尽管业内已有的开源工具均可以通过并发大量数据库连接结合一定的查询语句来制造出一定的SQL流量，达到模拟业务高强度使用数据库的效果。但是，在使用了真实的且有一定数据倾斜的业务模型之后，会发现一个比较严重的问题：假如多次测试同一个模型同一份数据在RDS MySQL下的性能效果，在数据有倾斜的情况下，两边的性能曲线很可能对不上。例如，第一轮压测在A时间点查到了某一个数据，而第二次压测很可能在B时间点才查到，这样对分析问题就有了很大干扰，如图5所示，两条曲线虽然压力差不多，但是抖动频率完全不一致，不利于分析。

图5 同一个数据库实例上跑两次相同的测试模型的效果

针对这种情况，我们提出了压测幂等的概念，即相同的测试，无论运行多少次，产生的SQL是完全一致的。在幂等情况下，每个时间点产生的SQL文本是完全相同的（假设数据库处理能力完全一致），并且整个压测任务中，所有SQL的执行顺序是一致的。目前做到了线程级别完全一致，不同线程之间从性能和需求的角度考虑没有实现强一致。

在幂等技术的加持下，DAS智能压测可以针对前文描述的场景可以做到一致性的压测，效果如图6。

图6 同一个数据库实例上跑两次相同的智能压测的效果

压测幂等的技术主要从压测线程生成逻辑、总请求数、写入最终一致性这三方面进行处理，让压测过程中可以确保每个线程内部出现的随机数的顺序都是一样的，并且不同线程之间不一样；通过保持线程中请求量总数一致，达到确保总请求量固定的效果；再结合自定义主键和约定update区间的方式，规避了自增主键和update冲突问题，确保了压测结束后的数据最终一致性。

4. 产品落地

4.1. 产品流程

介绍完智能压测的组成部分和对应的核心技术之后，下面来看DAS是如何将智能压测落地成产品。从压测的流程来看，整个智能压测的过程可以分为准备阶段、SQL处理阶段、回放阶段和效果评估阶段，如图7所示。

图7 智能压测产品流程

准备阶段主要是解决压测的机器环境问题，涉及从购买ECS机器、准备压测目标实例、配置ECS机器上的运行环境等。目前DAS的智能压测可根据压测流量的QPS和回放时长，自主选择合适的ECS机器并自动配置运行环境，也允许用户采用利用自有机器进行压测。在准备压测目标实例环节，现在DAS可通过RDS备份恢复、DTS同步的方式来自助帮助用户准备好目标实例，也允许用户自由指定压测实例。

SQL处理阶段则主要是对压测使用的全量SQL明细数据做压测前的数据准备，基于SQL洞察明细或者智能算法生成的SQL数据做预处理，包括prepared statement语句去重、日志剔除、事务语句合并等等操作。

在回放阶段主要是利用压测幂等技术将流量进行回放，提供了实时的数据库性能数据和压测机器负载情况，便于用户了解压测进度。在此环节中，DAS将智能调参算法与压测进行了结合，用户可通过该功能实现参数调优的功能，具体算法实现将在后续文章单独介绍。

效果评估阶段主要是解读压测过程中的指标数据，DAS对业务调优中常用的性能参数和关键性能指标做了对比，协助用户做出资源评估决策。对于压测过程中发现的慢SQL、锁等问题，DAS也提供了相应的改进建议和处理方法，对用户优化业务也提供了信息辅助。

4.2 产品使用

用户可以在DAS控制台的左侧菜单“智能压测”进行使用，如图8。目前DAS支持RDS MySQL和PolarDB MySQL压测，其他关系型数据库引擎的支持正在开发中。

图8 智能压测界面

在压测结束之后，用户可以通过任务详情查看到目标实例与源实例的性能数据对比以及关键参数的对比，如图9所示。

图9 压测后的效果对比

4.3. 产品计费

目前DAS智能压测功能未单独收费，压测流程中新创建的ECS、RDS均按照对应产品官网中以按量计费的标准进行计费，无额外服务费用。如前文所述，压测依赖源端全量SQL明细数据或相应库表基础结构数据，故该服务仅需要压测源端实例开启DAS专业版功能即可。

4.4. 客户案例

DAS智能压测服务自2020年上线以来，主要客户为云上头部客户，已累计为近百个客户提供服务，主要包括上云资源评估、业务大促评估、引擎切换评估、数据库操作验证等场景。

5. 未来规划

接下来，智能压测将增加支持的数据库引擎，覆盖云上的所有关系型数据库引擎；同时，智能压测将会贴近客户的真实业务问题，与用户上云、资源评估、引擎推荐等场景密切结合，并提供相应的压测评估建议和报告，与企业客户一起构建大规模场景下的数据库容量规划能力。

7月7日14点数据库自治服务DAS年度重磅发布

DAS自治胜似闲庭信步

数据库自动驾驶进入规模化时代
扫描下图二维码或点击“这里”预约观看直播

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

到这里，我们也就讲完了《深度技术揭秘 | 大促狂欢背后，如何有效评估并规划数据库计算资源？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于mysql的知识点！