线上遇到慢接口的解决方案

一、背景

某一天早上，正在上班路上，突然间手机滴滴不断收到大量告警提醒，赶紧查看了下告警信息，结果显示某个接口出现大量超时，平均响应时间超过3s，这个时候怎么办，是不是有点慌?

二、此类问题解决思路

出现生产问题，我们绝对不能马虎放过抱着侥幸心里，必须要找到根本原因及时处理，防止下次留下更大的坑。那我们的处理思路是什么呢?我这里给大家分享以下

1)定位问题
首先我们要快速定位接口的哪一个环节比较比较慢，性能瓶颈在哪里?这个时候可以采用APM工具快速定位，常见的工具:skywalking、pinpoint,cat、zipkin假如我们应用没有接入APM，可以在生产环境装一下阿里的A.rthas，利用trace接口方法，大概能分析是哪一块比较慢，定位的力度稍微有点粗糙

2)解决办法
．扩容(应用自动扩容、redis扩容、mysql在线扩容、kafka分区扩容)．应用重启大法
．优化代码逻辑，走hotfix发版解决

三、常见优化接口性能方案分析

1）数据库慢SQL
通过explain执行计划分析下
．锁表(先把锁表的慢SQL kill一波)
．未加索引
．加了索引，索引失效（对索引加方法转换、区分度很低比如枚举值、索引列大量空值)．小表驱动大表(尽可能过滤数据)
.SQL太复杂(join超过3张表或者子查询比较多，建议拆分SQL为多个按口，比如先从某个主接口查某个表数据，然后关联字段作为条件从另外一个表查询，进行内存拼接）
．返回的数据量数据量太大(可以分页多批次查询，可以非c端可以考虑多线程查询)
．单表数据量太大（考虑放分片库或分表或者clickhouse、es存储)

2)调用第三方接口慢
．调用第三方设置合理的超时时间，比如你的接女是高并发接口，从自身对方接口的要求和对方线上P95接口的平均rt，综合设置超时时间
．集成sentinel或hystrix限流熔断框架，防止对方接口拖垮我们自己的接口
. 事务型操作根据实际的情况酌情决定是否重试补偿(本地消息表+job重试)，比如新增、修改等操作要考虑对方接口是否支持幂等，防止超发
．循环调用，改为单次批量调用，减少IO损耗(比如调用AB接口，根据用户ID、分组ID多个，for调用改为一次传多个分组ID)
．缓存查询结果(比如根据用户ID查询用户信息)

3)中间件慢
. redis慢(是否有热key、大key，热key:上本地缓存，大key:拆分大key或者采用se t结构的sismember等方法判断-O(1)时间复杂度)
. kafia慢（生产端慢:向kafka丢消息慢了，可以使用阻塞队列接收，批量丢消息等优化～消费端:扩分区、增加消费节点、增加消费线程或批量消费批量写库)

4)程序逻辑慢
．非法校验逻辑前置，避免无用数据穿透消耗系统资源，减少无效调用
. 循环调用改为单次调用（比如查数据库或查其他rpc或restful接口，能批量调用尽量批量调用，数据在内存组装处理)．同步调用改为异步调用（采用completableFuture异步非阻塞，并行调用不同的rpc接口)