美团数据库团队推出了数据库容量评估系统，旨在解决数据库容量评估与变更风险防控等领域难题。本文介绍了系统架构和主要功能：系统使用线上流量在沙盒环境回放验证变更安全，结合倍速回放技术探测集群性能瓶颈，构建容量运营体系实现集群容量观测与治理闭环。系统具备数据操作安全、结果真实可靠、灵活高效赋能等特点，有效提升数据库稳定性与资源利用率。
本文目录
-
01 项目背景 -
02 项目目标 -
03 能力全景 -
04 流量回放 -
4.1 业务场景 -
4.2 架构设计 -
4.3 效果展示 -
05 容量上探 -
5.1 业务场景 -
5.2 流程实现 -
5.3 倍速回放 -
5.4 效果展示 -
06 容量运营 -
6.1 业务场景 -
6.2 运营设计 -
6.3 效果展示 -
07 未来规划
01 项目背景
数据库作为业务系统的核心基石，其重要性不言而喻。随着企业业务规模的持续扩张和社会影响力的不断提升，企业对数据库稳定性的要求也达到了前所未有的高度。在日常保障工作中，美团数据库团队也面临着诸多挑战，常见痛点如下：
痛点一：活动期间数据库集群的读写容量上限难以准确评估，会出现容量不足导致生产事故。
常见的容量评估方法包括指标计算和全链路压测：
-
指标计算，通过比较负载指标与阈值的大小，判断节点是否健康，但流量与相关指标不是严格的线性关系，通过指标预测容量上限的准确性不高； -
全链路压测，通过录制上层业务流量并回放，能探测整条服务链路的瓶颈，但数据库流量会受压测场景复杂性、样本丰富度等多种因素影响，导致难以完全拟真，同时业务服务接入压测有一定的改造成本。
痛点二：数据库变更是引起线上事故的主要原因之一，风险变更难以识别。
常规的解决方法有固定规则拦截和线下测试：
-
固定规则拦截，将拦截规则集成到变更平台中，通过固定规则判断变更风险，但诸如增加索引、修改字段类型等常规变更通常不会被拦截，这类变更可能导致 SQL 执行效率变差，进而引起数据库性能下降甚至系统崩溃； -
线下测试，通过线下环境测试识别风险，但可能因为线下与线上数据存在差异，以及测试不够充分，难以准确识别出所有潜在风险。
02 项目目标
建设数据库容量评估系统，通过使用线上真实流量回放方法，构建一套完整的容量评估体系，为数据库容量规划提供科学的数据支撑和决策依据。容量评估系统在建设时有以下基本要求：
03 能力全景
-
压测平台：用户与系统交互的门户，提供流量回放，容量上探，容量运营，预算校准等场景的操作页面。 -
对外赋能：外部服务可通过调度系统提供的标准化接口（OpenAPI）应用回放能力，达成数据库流量回放能力赋能。 -
核心功能：系统核心功能涵盖三个关键场景，即流量回放、容量上探与容量运营，共同构建了从测试到运营的全链路容量管理能力。 -
基础能力：流量回放基础能力采用模块化架构设计，通过清晰的职责划分实现了功能解耦，大幅提升了流量回放的可操作性。 -
压测类型：数据库流量回放能力在初期建设时并没有设限，只要是支持 SQL 协议的测试数据库目标或周边组件，均可以通过相应改造进而支持。
接下来我们将结合实际生产中常见的数据库应用场景，深入解析本系统流量回放、容量上探、容量运营三大核心功能及其对应的实现方案。
04 流量回放
评估的准确性是项目至关重要的考核指标之一，我们通过录制在线流量、构建沙盒环境并执行流量回放，以评估数据库集群性能。在数据库运维领域中，变更是高频高危操作，如参数调优、慢查询优化、版本升级等，那如何判断其变更后的效果和稳定性呢？下面将通过实际案例来介绍-流量回放。
| 4.1 业务场景
| 4.2 架构设计
图 2 流量回放流程图
我们通过录制线上数据库流量，并将其拟真回放到隔离的沙盒环境集群中，构建了一套完整的流量回放与分析能力。这一方案为运维变更提供了安全可靠的沙盒测试环境，能够在模拟真实流量的条件下验证变更方案，有效降低了生产环境风险。
完成整个流量回放测试需要以下四个核心流程：
流量采集（Traffic Collect）
该流程负责录制线上流量，为后续回放动作提供原始 SQL，此流程有三个重要模块。
流量处理（Traffic Process）
该流程负责对采集的 SQL 流量进行聚合、处理和固化处理。
流量回放（Traffic Replay）
该流程负责消费流量文件并在沙盒环境中实现流量回放，具体详细架构设计参考图 3。
数据分析&报告（Data Analyze & Report）
该流程集成数据采集与分析能力，支持线上及沙盒环境的多维度数据采集，为用户提供全面、精准的可观测性支持，主要包括：
| 4.3 效果展示
图 4 流量回放报告-SQL 执行情况对比
流量回放分析报告会展示其恶化 SQL Top3、提升 SQL Top3 及 SQL 性能详细对比结果，从上述分析报告中可得出，开启表压缩后，执行最多的 SQL 耗时从 0.90ms 增加到 0.97ms，未出现明显下降，同时存储占用空间是原来的 40%，基于回放测试结论，小美的集群启用表压缩功能，执行表压缩变更后，系统稳定运行，磁盘空间不足问题得到缓解。
在美团，流量回放还在索引变更性能验证、数据库版本升级兼容性测试等场景中广泛运用。
05 容量上探
上述变更场景的流量是按在线一倍流量回放，而在实际业务诉求中，用户希望评估集群可承受的最大 QPS 是多少，能承受当前最大几倍的流量。下面将通过实际案例来介绍-容量上探。
| 5.1 业务场景
| 5.2 流程实现
图 5 流量上探流程
容量上探功能基于业务高峰期采集真实流量样本，在沙盒的测试环境中自动执行多轮加速回放测试。通过渐进式压力调节，逐步逼近数据库性能极限，最终探测到集群的最大承载读写 QPS。
超载标准
集群容量与告警紧密相关，用户根据业务场景为 RDS 集群设置相应的告警策略，集群出现告警表明集群超载。
沙盒环境
用户可根据实际需求灵活调整压测沙盒环境配置，如机型、MySQL 版本、核心参数等。在评估线上集群容量上限的应用场景中，为保证上探结果更真实准确，沙盒环境集群配置要求与线上集群保持一致。
上探流程
容量上探采用循环迭代的评估方式，每轮流量回放后，沙盒环境自动进行数据回滚，分析器会检索本轮告警，并对是否触达上限进行标记，同时计算下一轮回放速度。评估过程分为两个关键阶段：
| 5.3 倍速回放
容量上探通过调整回放倍速模拟流量增长，倍速回放通过压缩 SQL 执行间隔，提升单位时间内的请求密度，从而增加数据库负载压力。
在回放 agent 内，SQL 处理与回放处理的流程如下图所示：
回放进程会为流量文件中的每一个待执行的 SQL 分配一个执行协程，在协程内部由 CalcSendTime 函数对 SQL 回放的时序进行精准控制，该机制具体实现如下：
-
当 planDelta >= realPassDelta 时，协程会等待差值 waitTime 时间后再执行 SQL，理想情况是 SQL 都进入该分支等待执行。 -
当 planDelta < realPassDelta 时，SQL 会立即执行 ，若大量出现这种情况，表示当前协程处理并发不足可能会导致回放失真。
这种时序控制机制确保了 SQL 回放过程能够准确匹配预设的回放速度，从而实现了可靠的倍速调节能力，SQL 倍速回放时序控制效果如下图所示：
图 8 SQL 倍速回放时序控制示意图
| 5.4 效果展示
图 9 容量上探报告-上探过程展示
容量上探报告会展示容量上探结果、不同倍数压测结果。从上述报告中可以看出，业务集群降低机器配置，流量到达 6 倍以上时才触发集群告警，完全满足业务 2 倍容量诉求，最终小美选择对该集群进行降配，降配后服务运行稳定。
在美团，容量上探还在服务器性能对比测试、数据库参数调优验证等场景中广泛运用。
06 容量运营
面对业务活动时，业务方希望 DBA 给予所有集群的容量状态的评估，当前所负责的集群处于什么水位线，是快到瓶颈、还是冗余很多？这里我们构建了容量运营服务，即时掌控集群容量状态。
| 6.1 业务场景
| 6.2 运营设计
容量运营是集成了三个核心功能模块：容量评估托管、容量计算和自动化运维，为大规模集群容量观测提供了便利入口，同时通过一站式运维管理，实现运营与治理闭环，显著提升运维效率。
评估托管
容量计算
自动化运维
| 6.3 效果展示
容量运营报告展示集群主从、读写的容量使用水位以及容量建议，小美通过运营页面直观查看到所负责集群的容量状态，针对存在容量风险的集群，按照系统给出的容量建议完成了数据库扩容拆分工作，这一系列举措简化了以往复杂的评估流程，大幅提升了工作效率。
07 未来规划
---------- END ----------