大促准备（七）压测

压测分为全链路压测和单系统服务接口压测两种，对于全链路压测要准备的事情和要改造的东西是特别多的，是一个相对庞大的系统工程，大体业务架构以下，能够单独列出一个系列来说，这里只讲单系统的服务接口压测。

压测能够选择的框架有多种，能够根据系统所采用的代码、熟悉程度等选择一个，更好的方式是在开源的压测框架之上开发一个压测平台，下降学习成本，方便统一管控。下面的流程是假设公司内部有统一的压测平台展开的。

1.压测工单申请|压测通知

压测时会对应用服务器、db、消息中间件、缓存、下游系统等关联系统形成影响，于是须要和关联方进行告知或者申请，同步信息，获得确认后再开始

2.压测数据准备

在前面的压测改造和准备小节也提到过压测数据的准备，根据业务的需求若是能够mock的数据必定要保证mock的数据足够的随机同时要保证压测数据和线上正式数据是隔离的；对于缓存数据须要可能还须要进行预热；对于不能mock的数据要保证脱敏而且后续的操做不会感染用户的真实数据；

3.压测脚本联调

在准备好数据后，须要对压测脚本进行联调，确保压测脚本符合预期：
1）业务逻辑是否符合预期
2）总调用量是否符合预期
3）db调用量是否符合预期

4.压测预案准备

压测预案和高峰期的预案可能相同，也可能不一样，好比压测时的缓存命中率就是压测专用的，为了方便各类开关的推送，最好把压测相关的预案配置到一个预案中，方案统一执行和管控

5.压测限流准备

在进行压测时，线上仍然是有正常的流量进来的，于是对于接口的限流配置要仔细规划。能够针对压测流量进行单独的限流，也能够对全部的流量进行限流。若是是前者，能够保证限流只做用于压测流量，不会影响到线上业务；若是是后者当压测流量比较大时就会影响到正常流量，可是能够利用这个机会验证下限流是否生效。两种方式各有利弊，能够根据本身的业务状况进行取舍。

6.压测服务器申请

压力测试也是由服务器发出请求的，于是要根据本身的目标请求量申请足够的压测服务器，不然也没法达标。

7.肯定合适的上量速度

大促活动的上量速度一般是很是迅速的，可能在几秒中上升到平常的十几倍或者几十倍，可是在压测的时候特别是第一轮压测时候上量须要慢些，留出比较长的观察时间，以进行验证，当出现异常状况时能够快速定位问题和快速回滚。
当压测达标后再次进行压测时能够比较快的上量，尽可能模仿真实的状况。

8.数据记录&复盘

将压测达标时系统的主要数据进行记录：cpu、load、峰值、rt、error、内存、gc等。这些数据将会对后续的压测及平常其余系统接入进行容量评估十分有帮助。

复盘主要是针对压测中预料以外的事情进行回顾，分析产生的缘由以及以后如何避免，对产生的问题可能还要去修改脚本、预案、限流、代码等内容。