大促准备（七）压测

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

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

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

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

2.压测数据准备

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

3.压测脚本联调

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

4.压测预案准备

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

5.压测限流准备

在进行压测时，线上仍然是有正常的流量进来的，因而对于接口的限流配置要仔细规划。可以针对压测流量进行单独的限流，也可以对所有的流量进行限流。如果是前者，可以保证限流只作用于压测流量，不会影响到线上业务；如果是后者当压测流量比较大时就会影响到正常流量，但是可以利用这个机会验证下限流是否生效。两种方式各有利弊，可以根据自己的业务情况进行取舍。

6.压测服务器申请

压力测试也是由服务器发出请求的，因而要根据自己的目标请求量申请足够的压测服务器，否则也无法达标。

7.确定合适的上量速度

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

8.数据记录&复盘

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

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