解决思路：

1）定位问题 traceId分析调用链路的各阶段的用时，找到耗时长的地方。skywalking、Arthas

2)解决方法：

数据库慢sql:

通过explain执行计划分析，可能存在以下问题；

  • 锁表
  • 未加索引、未走索引
  • sql语句编写不规范，是否是小表驱动大表，是否join的表超过三张
  • 单表数据量是否太大，考虑分库分表

调用第三方接口慢： 

  • 计算平均的接口请求时间，设置合理的超时时间，过了超时时间直接返回。例如：业务高峰期，服务不稳定，超过了超时时间，则可以快速失败，然后重新请求，可以把重试的次数和时间放配置中心，如果事务性操作，插入、更新，需要考虑幂等性。
  • sentinel或hsytrix限流熔断框架，防止被第三方接口拖垮
  • 循环调用是否可以更改为单次批量调用，减少IO损耗
  • 缓存结果

中间件慢：

  • redis是否存在热key，考虑上本地缓存，guava Cache,设置refreshAfterWrite刷新策略；是否存在大key，可以做拆分 

 程序逻辑慢：

  • 非法校验逻辑前置，减少无用数据穿透
  • 循环调用改单次，减少IO
  • 同步改异步 串行改并行，如completableFuture、mq 。例如：用户查询信息接口需要去调用户查询接口200ms、积分查询接口150ms、成长值接口100ms。此时，如果逐一调用，那总耗时就是三个接口合起来的值200+150+100ms。如果改并行调用，只需要最长时间的值200ms。又例如，用户新建账号，需要发短信、记录操作日志，发短信以及记录操作日志不影响我们主流程，此时就可以用mq去处理。
  • 锁是否合理，锁力度太大，或者设计不合理，悲观锁是否可以替换为乐观锁？
  • 日志打印是否有必要？
  • 优化gc参数
  • 查询限制数量，进行分页查，避免一次性查询数据过多。滚动分页，前端可以返回上一次查询的最大结果，然后后端根据结果去查下一页数据。