概要
本文是根据自己压测的经历总结出来的小本本，遇到压测的时候提前看一眼，能节省自己的时间，少熬夜，有说的不对地方，欢迎大家评论留言。
压测原则
我觉得性能优化是个持续的过程，所以我们得有原则的去执行，有4个原则
- 压测期间，除非bug，否则尽可能不改或者最小范围的改动代码
- 以各种监控为主、服务日志为辅定位和优化性能问题
- 在可容忍的区间内优化性能，尽量避免扩大工作面
- 大版本变更的压测，最好是结对压测，处理复杂问题能高效
粗俗一点讲：尽量不改代码、优化有度、找一只合适的小黄鸭
压测常见问题
压测可能会遇到这些方面的问题：缓存、数据库、同步处理逻辑、程序内部问题、下游依赖的性能问题
缓存
使用复杂度高的命令：
使用O(n)或者更高复杂度的命令，但是未严格控制n
设计的缓存数据不合理：
key拆分过细，导致一次请求多次IO，随着业务复杂，单次业务处理的时间复杂度越来越高
key不拆分形成大key，单次响应体积过大，影响性能
redis连接配置不合理：
不合理的空闲检测时间，没有针对业务高峰期预热线程或者连接，导致建连接会阻塞住业务逻辑
数据库
索引问题
缺少或者设置错误索引，导致一次查询太多数据，甚至慢sql
数据缓存问题
没有恰当的采用缓存，导致sql次数太多
同步处理逻辑
过多同步逻辑：
同步业务中处理了过多时效性不高的逻辑
异步逻辑访问db不加控制：
一个业务逻辑可能会发出多个消息异步入库，一旦遇到请求尖刺，异步入db的请求放大比非常明显
程序内部问题
业务代码问题
比如业务代码中申请了大对象，或者是在循环中处理业务逻辑，导致gc出现卡顿
rpc依赖产生的性能问题
错误处理不合理
调用下游业务的超时不合理，过长或者过短
调用下游的重试次数也不合理，过多或者过少
常见应对措施
我们对症下药，逐个来说
缓存问题解决
减少缓存IO
小key整合，大key拆分，控制缓存IO的放大比和单次请求的响应体积
及时盯着redis的slowlog，尝试优化占比最大或者耗时最长的几个命令
热点的数据随机打散存储， 降低单台缓存服务器的IO
使用本地缓存优化热点数据
将数据分片存储，减少本地缓存的存储空间
写热点数据时使用多备份，减少集群请求不均的情况
保存数据时，存上100份，请求时随机读数据，让请求分散到多个redis-server上
同步处理优化
找出可以异步的逻辑，转入消息队列
消费消息写db时，增加db限流保护
程序内部问题
手动预热线程池和资源连接
如果有尖刺场景，提前预热的资源池线程
检视代码，减少大对象的逻辑
比如使用stream替换for，减少暂存结果的中间变量，避免一种大对象的case
rpc重试和异步重试
做好本地重试
对于下游依赖的性能问题，需要协调下游做针对性优化，没得说
处理好错误响应
设置降级响应，减少系统性能问题导致的影响面
控制rpc放大比
监控服务间rpc的次数，及时对同一个rpc的多次调用，及时将rpc的结果缓存到堆栈上，或者将多次调用合并为同一个