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

简介： 经过“双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也提供了相应的改进建议和处理方法，对用户优化业务也提供了信息辅助。