当接口（系统）碰到性能问题该怎么办

1.身体检查

做一次压力测试，可以了解系统大致的性能

压测建议：

1. DB:压测有写流量要先建影子表
2. tair:压测有写流量绕过tair写
3. HSF:压测流量绕过依赖应用有写操作的HSF

2. 病因诊断

当问题复现的时候，就可以对系统开始诊断了，对于一位医生，如何分析身体检查的结果数据是至关重要的，这里推荐4个平台

机器承载能力和系统异常结果：查看机器各项性能指标情况

系统依赖和服务耗时结果：查看全链路的各个环节服务的调用情况

JVM堆内存和线程详情： 查看具体内存和线程情况

数据库和SQL问题结果： 查看数据库情况，是否存在慢sql

3. 对症治疗

优化：在互联网系统中，背景中描述的问题可以当成一个典型的秒杀场景来优化解决，结合一些文章我将自己的思考整理为横向优化和纵向优化，

纵向优化

热点隔离：禁止1%的请求影响99%的请求，关键在于识别是那个环节是热点
动静分离：静态数据和动态数据隔离
时间分片削峰：拉长峰值，减轻系统压力
依赖降级：对于耗时长的弱依赖做降级，对业务有影响这个需要加入开关控制

横向优化

物理层：宿主机、数据库、缓存等
服务层：业务处理逻辑领域层
应用层：客户请求、页面资源等
将横纵结合可以实现多种优化方案，这里举例关于解决本文遇到的问题而使用的优化用策略：

物理层：

1. 对耗时较长的SQL查询结果做缓存，减少数据库查询次数，如：对活动页面查询近半年所有活动的结果放入缓存，缓存方案是本机缓存过期时间30秒，这个功能对数据一致性会有30秒延迟，所以需要加入开关控制，日常情况下可以关闭缓存功能，在秒杀活动时打开缓存开关—热点隔离
2. 对于慢SQL做索引优化，避免影响其他sql的查询，如：查询每个人近半年参加的的活动，对gmt_creat(活动时间)加入索引，避免每次查询数据库扫描多余的数据，缩短查询耗时—热点隔离
3. 加大线程池，数据库线程池从10增大到20，后续和DBA交流了解到数据库线程池不能也不会加太大，因为有可能会拖垮其他的数据库，这里推荐DBA@志歉的Mysql原理介绍，干货满满。
4. 单库单表修改为分库分表，改造投入时间较长先不考虑。

服务层：

1. 对复杂的代码查询逻辑做拆分，将弱依赖查询拆分，同时对长文本字段的DO对象查询放到业务逻辑处理的最后执行，这样从400个全量DO对象的长文本堆存储降为只查分页中第一页的5个DO对象，缓解堆空间的使用情况解决FullGc问题。
2. 对耗时较长的弱依赖RPC服务添加降级处理开关控制，这点会影响页面个别逻辑展示，需要和业务方沟通—依赖降级。
3. 活动中心页面接口是个通用型接口，有非”活动中心页面“的渠道请求该接口接口，请求中有复杂"活动与用户相关逻辑处理"也就是1078次数据库查询的原因，对特定渠道的查询隔离避免活动中心页面请求也会有1078次数据库查询—热点隔离。

应用层：

1. 做限流控制，对影响活动页面的其他http页请求—热点隔离、时间片削峰
2. 页面可以展示后，高峰流量可能会压到点击报名上，后续的考虑用点击报名弹验证码来应对同一时间的高峰qps，但是后续压测和ROI考虑暂时不需要：因为这个写是分库整个链路耗时为34ms—时间片削峰。
3. 秒杀活动单独做活动页面承接，这样就可以把一些静态资源放到CDN上，后端只返回动态的数据，但因为前端资源和投入时间问题本次没有开发—动静分离
4. 把底层逻辑改动的对客户的相关影响挂在页面公告，防止增加用户过量咨询

4. 身体复检

重新做一遍压测，观察性能问题

1. 优化后压力测试系统抗压能力qps：20-> 1980，性能提升80倍，同时支持水平扩展。
2. 接口流量高峰耗时：从8567ms-> 45ms,
   3.一次http服务从数据库请求1078次减少到53次
3. 慢sql已经没有。
   5.优化逻辑发布后系统Old区内存空间从800Mb降低到100Mb左右，在qps峰值时未出现过一次FullGc