本文始发自博客：[服务端压测怎么做](https://zingpho y.github.io/2020/04/26/%E6%9C%8D%E5%8A%A1%E7%AB%AF%E5%8E%8B%E6%B5%8B%E6%80%8E%E4%B9%88%E5%81%9A/)
博文的内容并不都是我原创的，行文思路来源于一次内部分享，再结合网上众多参考资料总结出来的，算是一个学习笔记。
可能很多QA、RD同学跟我都一样，对服务端压测一直没有系统的认知，印象停留在使用压测工具如Jmeter对单接口发压，调整线程数和循环数来制造不同压力，最后计算一下TPS和成功率等就完事了？网上虽然有不少压测相关的文章，但多数是压测工具的入门级使用，有的是压测流程和指标的简单解释，或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述，要不过于抽象不好理解，对没怎么接触过压测的同学不太友好。
本文尝试在QA角度梳理一次完整的压测过程，尝试总结更为普适的压测思路，给大家提供更有意义的参考。
压测背景
测试分很多种，网上很多文章[1]会玩弄概念，搬出来3个名词：压力测试（Stress Testing）、性能测试（Performance Testing）、负载测试（Load Testing）。一般情况下并不需要做这么细粒度的概念区分，这3个概念我觉得是没办法完整区分各自边界的，至少在程序逻辑上难以做得到，更多差异只是来自于不同的压测策略，所以尽管忽略这几个概念的区别，都叫它压测或者性能测试即可。
为什么需要压测
拿技术人熟知的阿里举例，应该是国内做压测最好的一个大厂。外界熟知的阿里2012双11活动，2012年11月11日零点，阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失，系统显示交易成功率不到50%，产生了大量超卖，给阿里带来很大的损失。那一年的双11后，库存、商品、退款和相应数据库的同学，为了处理超卖导致的问题，没日没夜加了两周的班，同时给了用户不少糟糕购物体验。
为什么出现这么严重的问题？因为对整个全交易链路上的各个子系统的承受能力不清楚，并且错误预估了可能会达到的流量，也没有完善的预案，兵败如山倒。
2013年阿里首次提出了全链路压测方案：一方面可让链路的各个系统知道自己的承压极限；另一方面可让各个系统有个明确的优化目标，了解到整个链路的瓶颈并评估资源情况。
单系统压测与全链路压测
为什么只做单系统压测还不够呢？
在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。
所以最可靠的方式是完全模拟真实场景来压测，通过线上全链路压测提前发现问题。
压测流程
完整的压测流程一般包含下面几个步骤，引用自文末参考资料：
- 压测目标的制定
- 压测链路的梳理
- 压测环境的准备
- 压测数据的构造
- 发压测试
- 瓶颈定位及容量微调
- 压测总结
压测目标
压测作用
- 新服务，无预估目标，需要通过压测得到服务基准数据或找到系统瓶颈进行优化
- 有明确的压测目标，需要通过压测确定服务的各项指标是否达标
- 常态化压测，为后期性能优化指导方向或提供参考依据
压测指标
列举一些常用指标，并不一定都需要关注，根据业务考虑指标的细化粒度。
- QPS：Query Per Second，每秒处理的请求个数
- TPS：Transactions Per Second，每秒处理的事务数，TPS <= QPS
- RT： Response Time，响应时间，等价于Latency
RT分平均延时，Pct延时（Percentile分位数）。平均值不能反映服务真实响应延时，实际压测中一般参考Pct90，Pct99等指标 - CPU使用率：出于节点宕机后负载均衡的考虑，一般 CPU使用率 < 75% 比较合适
- 内存使用率：内存占用情况，一般观察内存是否有尖刺或泄露
- Load指标：CPU的负载，不是指CPU的使用率，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，表示CPU的负载情况，一般情况下 Load < CPU的核数*2，更多参考链接1和链接2
- 缓存命中率：多少流量能命中缓存层（redis、memcached等）
- 数据库耗时：数据库就是业务的生命，很多时候业务崩掉是因为数据库挂了
- 网络带宽：带宽是否瓶颈
- 接口响应错误率 or 错误日志量
这里要说明一下QPS和TPS的区别：
- QPS一般是指一台服务器每秒能够响应的查询次数，或者抽象理解成每秒能应对多少网络流量
- TPS是指一个完整事务，一个事务可能包含一系列的请求过程。举个