# 容量评估方法

+ 基准测试法
+ 经验评估法
+ 历史数据分析法
+ 业务流量压测法
  + 测试环境
  + 线上引流
  + 全链路

----------------------------------------------------
- 基准测试法
基准测试法是通过对指定配置的数据库系统通过一些通用的基准测试模型（Sysbench、TPC-C、TPC-H等）进行一系列压力和性能测试，在满足吞吐量、数据量、响应时间、复制延时等业务需求前提下，来获得数据库容量评估数据。
通过该方法可以获得指定配置数据库在指定测试模型和用例下的容量数据，可以为数据库评估提供基本的参考。但是该方法只能一定程度的反应数据库的真实容量，因为真实业务的数据和访问模型和基准测试模型很难完全相同，所以还需要根据这些差异，对容量数据进行一定程度的校准。

- 经验评估法
基于运维人员的经验来评估，经验丰富的运维人员针对不同的业务场景，根据历史经验估算出业务需求的数据库集群规模。
该方法依赖于运维人员的经验和见识，运维人员基于管理过的类似业务场景的经验来进行大概的容量评估，如果遇到没有接触过的场景，则可能无法进行评估，并且就算类似场景，实现逻辑也会有些许不同，都可能影响经容量验评估的准确性。

- 历史数据分析法
对于已有集群一般会首先使用的是历史数据分析法来评估数据库容量，历史数据分析方法是根据过去的数据增长趋势和变化预测未来的数据量。通过对历史数据的综合分析，可以获得相对准确的数据库评估结果。这个方法的难点是在于预测，简单的是运维人员根据监控数据中流量和数据库指标（CPU、Disk、Lantcy等）的关系评估，复杂的就是根据数学统计学回归分析，根据历史数据进行分析和预测容量的方法。
该方法获取的容量数据相对是比较准确的，如果分析模型没有问题的话，获取的容量数据就是根据该业务历史上业务模型的容量。但是业务模型也是在不断的变化中的，当业务模型变化后，评估的数据准确度就会受到影响。

- 业务流量压测法
以上三种容量评估方法都有一定的适用范围和限制，为了得到某个业务真实的容量，比较专业的公司一般会通过业务压测来实现。业务压测是尽量的模拟业务场景，构造测试流量，对业务进行各种场景的测试验证，持续发现瓶颈和调优，保障系统稳定性的一个技术工程。其中业务压测又分为以下几种常见的方案：

  - 测试环境压测
    - 在测试环境进行压测，一般是针对一些重点项目进行这种测试手段。但是不管是在线下 QA、DEV 或者预发布环境进行，都难以 100% 复制线上生产环境的数据量、硬件资源、并发量等，所以压测出来的数据无法保证 100% 反应线上的容量数据。

  - 线上引流压测
    - 随着业务容量要求的不断提升，考虑到线下测试结果的准确性问题，有的企业开始尝试生产压测，这种压测手段，称之为引流压测。通过将线上流量引流和放大后应用到指定的集群上来进行容量评估。引流压测的场景相对比较接近业务真实场景，但是毕竟流量经过了放大等处理，所以也并不是 100% 相同，并且对线上生产也有一定的侵入性，可能会影响线上的稳定性。

  - 全链路压测
    - 全链路压测是基于实际的生产业务场景、生产环境，模拟海量的用户请求和数据对整个业务链（通常是核心业务链）进行压力测试。该压测方案是所有压测方案中最接近真实环境容量的方案。但是该方案也是技术难度最高的方案，需要专门的工具和平台，需要克服流量染色（影子流量），数据隔离（影子数据），日志隔离，风险熔断等技术难题，因为是在生产环境压测，所以如果控制不好风险也是非常高的，这是一个复杂的系统工程，需要业务方、架构、运维一起参与建设，一般是一个自上而下的工作。

业务压测能相对准确的评估出数据库在该业务下的容量，但是获得的容量数据也仅仅适用于这一个或一类业务，不同的业务或者该业务模型发生变化就需要再次进行流量压测，实施成本时非常高的，一般只有在核心业务上才会用该方法来评估。

以上是关于容量评估方法的总结，实际实施某次评估过程中不一定只局限一种评估方法，因为容量评估涉及较多的中间数据评估和结果数据评估，企业可以综合使用多个方法来获取这些数据，尽量的提升容量评估的准确度。