服务端压测

一、压测准备

1. 方案设计：优先考虑待压测服务的现状和压测场景的复杂程度
   1. 压测服务现状：
      1. 线上稳定运行的服务有新增逻辑：判断对旧逻辑的影响，评估是否只压测新增模块相关功能即可
      2. 新服务有历史同类/类似业务参考：根据已有流量评估流量量级和性能瓶颈，看是否必要全量功能压测
      3. 新服务没有历史类似业务参考：拆分代码组成，预估全量功能的流量量级，明确是否需要单独摸底，是否需必须全量覆盖
   2. 压测配置的约定：压测流量做好唯一标识
   3. 压测数据处理：
      1. 数据构造：
         1. 压测数据是实时随着压测产生的，不需要单独构造数据
         2. 压测数据是需要前置条件的，那么就要考虑通过接口顺序编排就可以产生数据，还是需要提前人为构造
         3. 压测数据是需要完全拟合实际用户场景的，那么更要确认提前构造的方案，很多时候拟合用户操作的数据，还需要考虑同一个用户多接口并发是否有影响
      2. 数据清理：
         1. 永久存储数据，需要确认是否提单清理
         2. 非永久存储类数据，但对后续压测有干扰，那么需要单独清理
         3. 缓存类数据，不需要单独清理，设置好过期时间即可
      3. 压测影子隔离
         1. 流量标记的透传与识别，中间件的物理隔离，数据的逻辑隔离，Trace、监控、告警等配套基础设施，中台对压测的支持
         2. 影子表-压测数据构造
            1. 基础数据：如商品、商家等相关的数据，进行主键偏移（如item_id + 1k万亿；sku_id+1k万亿）；商家信息：从1800万压测账号中隔离出100万账号（seller_id%100wan + 16.15亿）；
            2. 增量数据：有时效性，如优惠券，营销活动，与资金有关，不能直接用统一的偏移方案，涉及到预算等校验，因此要采用实时数据构造
   4. 用例编排：
      1. 复杂场景：需要接口之间做好配合，不仅仅是时序和触发事件，还需要考虑接口实际作用效果的传递和实际作用产生的数据流转影响；需要分析用户行为和接口作用，评估明确如何排列/组合接口
         1. 返回依赖接口穿行
         2. 逻辑/用户行为驱动错峰
         3. 单用户动作接口并发
         4. 多用户多动作接口错峰叠加
      2. 简单场景：一般不需要考虑过多的接口时序和实际触发时机，只需要保证流量峰值即可，触发方式可以是：接口独立执行、顺序执行、同步并发
2. 流量录制：NGINX服务copy真实请求数据写入到MQ中，消费MQ消息，根据自身业务逻辑对原始数据进行二次加工（数据脱敏+偏移操作），下游consumer对经过业务处理的数据进行持久化，如写入hive/文件等等，持久化存储

二、压测执行

1. 压测类型
   1. 单机单接口摸底：往往实在不清楚单机抗压能力、需要验证单接口性能水位的时候需要从单机开始摸底，找到单接口下单机可抗压力峰值，且可以缩放查看单接口性能是否有潜在风险
   2. 单机多接口摸底：更拟合实际线上多接口共用资源的场景，能够模拟真实请求发生的标准情况下单机抗压能力的水位
   3. 单机限流值摸底
   4. 单机接口集群能力验证：保证大数据大并发的情况下，查看单个接口峰值下是否存在集群性能问题，使用单接口的好处则是能够排除多接口的干扰，更好的观测单个接口峰值下的性能表现
   5. 多接口集群能力验证：模拟线上真实的情况，查看多接口峰值并发情况下集群能否保证可用性
   6. 多接口集群能力探顶：不确定服务集群能力或希望减少冗余资源投入
   7. 大促压测：核心rpc接口压测，单api接口压测，黄金交易链路（小黄车-商详-交易）混合场景压测，大促玩法活动压测，真实货品玩法混合压测
2. 执行
   1. 执行前确认压测配置已就位、干扰屏蔽已开启
   2. 执行中关注全链路服务、存储的监控报警情况，做好随时止损准备
   3. 每轮压测执行结束分析本次流量情况是否满足，服务性能表现是否符合预期
   4. 压测遇到性能问题，从入口到下游服务逐步分析
   5. 复压与上次压测作了哪些调整，用例是否要进行调整
3. 例行压测：1h巡检一次，发生异常后试试报警，避免接口不通、配置未实时更新

三、压测复盘

1. 复压：
   1. 遇到性能风险点：走正常的性能优化和修复流程，优化后再次压测达到预期效果为准
   2. 流量不贴合实际场景：需要根据用户行为重画流量地图，明确资源瓶颈点，再次发起压测
2. 持续跟进：沉淀经验和可提升点
3. 待改进点：
   1. 支付目前是通过压测商户隔离，未建设影子表，需要增加确保压测物理隔离安全能力
   2. 监控报警隔离
   3. 压测模型评估：业务运营输入目标，和研发一起增加压测模型评估环节

四、压测标准：参考阿里

1. 100%目标值=1.2倍*预估值：服务正常，不触发限流，99%成功率，P99读400ms以内，P99写800ms以内
2. 110%摸高值=1.1*目标值：服务正常，不触发限流，99%成功率，P99读500ms以内，P99写900ms以内
3. 150%限流值=1.5*目标值：服务正常，限流比例正常（50%限流，重点关注下游api的限流），99%成功率（含限流），P99读500ms以内，P99写900ms以内
4. 极限压测：自定义，符合RT、成功率、CPU利用率、内存利用率要求情况下的最大稳定QPS；数据库，Redis
5. 压测指标：
   1. 事务层面：RT（response time，平均响应时长）、TPS（系统处理的每秒事务场景），TPS = 并发数*RT
   2. 服务器资源层面：CPU使用情况、内存使用群里和持续表现，磁盘IO速度、上行/下行网速情况
   3. QPS（query per second系统处理的每秒查询请求数）、RPS（request per second，处理的美每秒请求数）

五、问题排查

1. QPS达到1200，服务出现NPE问题：下单服务强依赖分销溯源库，数据库出现主从延迟问题，优化下单流程，将分销溯源流程后置在订单支付成功后处理
2. 订单服务可用性掉底：SQL耗时增加，触发了间隙锁（对索引记录之间的间隙的锁，或者是对第一个索引记录之前或最后一个索引记录之间的间隙枷锁，为了防止其他事务在这个区间插入数据）导致
3. 压测失败排查流程：网络问题、客户端问题、服务端问题
   1. 网络问题：带宽、网络质量
   2. 客户端问题：客户端自身瓶颈
   3. 服务端问题：
      1. 软件：
         1. 平台：数据库-CPU/内存/硬盘/连接数，中间件-CPU/内存/硬盘/连接数
         2. 应用：业务逻辑/程序流程/慢SQL，如JVM参数不合理、容器配置不合理，慢事务，数据库设计不合理、程序设计问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等）
      2. 硬件：CPU/内存/硬盘
4. 常见问题：
   1. TPS波动大：
      1. 网络波动大：通过监测网络的出入流量来判断，找运维协助处理
      2. 其他服务资源竞争：使用TOP命令或者服务梳理排查
      3. 垃圾回收：通过GC监控命令排查jstat -gc，可以修改JVM的堆内存参数Xmx(最大值不要超过服务节点内存的50%)再次压测验证
   2. 高并发下大量出错：
      1. 短连接导致端口被完全占用：修改服务节点的tcp_tw_resul参数为1，释放TIME_WAIT socket用于新的连接
      2. 线程池最大线程数配置较小及超时时间较短导致，修改容器服务的server.xml文件中的配置参数，maxThreads最大线程数、maxSpaceThreads Tomcat最大连接线程数，maxSpareThreads请求等待队列中的请求数，connectTimeout等待超时的阈值
   3. 集群类系统，各服务节点负载不均衡：一般是SLB服务设置了会话导致请求只发到一个节点，修改SLB服务（F5/HA/Nginx）的会话参数保持为None
   4. 并发数不断增加，TPS上不去，CPU使用率低：
      1. SQL问题：没有创建索引，语句筛选条件不明确
      2. 代码中设有同步锁，高并发时出现锁等待
   5. TPS不断下降，CPU利用率不断下降：一般是线程block导致，修改线程策略
   6. 其他
   7. CPU使用率高但内存低：代码池空闲程死循环
   8. CPU内存都高的原因：
      1. 锁使用不当，多个线程进入死锁状态
      2. 某个线程因为某种原因进入WAITING状态
      3. 代码某个位置有阻塞性操作，导致调用超时
      4. 代码中有比较耗CPU的操作，导致CPU过高