1、 背景
某一天早上，正在上班路上，突然间手机滴滴不断收到大量告警提醒，赶紧查看了下告警信息，结果显示某个接口出现大量超时，平均响应时间超过3s，这个时候怎么办，是不是有点慌?
2、解决思路
出现生产问题，必须要找到根本原因及时处理，防止下次留下更大的坑。
快速定位问题
首先我们要快速定位接口的哪一个环节比较比较慢，性能瓶颈在哪里?
这个时候可以采用APM工具快速定位，常见的工具：skywalking、pinpoint、zipkin。假如我们应用没有接入APM，可以在生产环境装一下阿里的Arthas，利用trace 接口 方法，大概能分析是哪一块比较慢，定位的力度稍微有点粗糙。阿里开源Java诊断工具 Arthas 使用
解决办法
-
扩容(应用自动扩容、redis扩容、mysql在线扩容、kafka分区扩容)
首先要保证系统正常，所以如果是系统瓶颈，那我们可以做应用扩容；如果是redis节点cpu/内存使用率高，可以做redis扩容；如果是因为慢sql导致myql 扛不住了，也可以在线扩容mysql；kafka同理，如果是kafka消息积压了，那可以分区扩容；
简单说就是先让通过扩容使系统暂时恢复正常，不至于引起更严重的问题
-
应用重启大法
扩容只能使新的应用新的节点保持正常，但是对于已有的CPU 100%的节点，那可以通过重启，释放资源
-
优化代码逻辑，走hotfix发版解决
前面的都是应急的办法，在定位到对应代码后，终归是要通过优化代码来发版处理的。
3、常见优化接口性能方案分析
1. 数据库慢SQL
通过explain执行计划分析下
-
未加索引，加索引时对于一些大表，不要在业务高峰期加，不然容易会锁表；
-
加了索引，索引失效(对索引加方法转换、区分度很低比如枚举值、索引列大量空值)
-
锁表(先把锁表的慢SQL kill一波)
-
小表驱动大表(尽可能添加过滤条件)
-
SOL太杂(jon超过3张表或者子查询比较多，建议拆分SQL为多个接口，比如先从某个主接口查某个表数据，然后关联字段作为条件从另外一个表查询，进行内存拼接)
-
返回的数据量数据量太大(可以分页多批次查询，管理端可以考虑多线程查询，C端高并发不建议多线程查询)
-
单表数据量太大(考虑放分片库或分表或者clickhouse、es存储)
2. 调用第三方接口慢
-
调用第三方设置合理的超时时间，比如你的接口是高并发接口，从自身对方接口的要求和对方线上P95接口的平均rt，综合设置超时时间，超时时间应该大于对方线上P95接口的平均rt；
-
集成sentinel或hystrix限流熔断框架，防止对方接口拖垮我们自己的接口；
-
事务型操作根据实际的情况决定是否重试补偿(本地消息表+jb重试)，比如新增、修改等操作要考虑对方接口是否支持幂等，防止超发；
-
循环调用，改为单次批量调用，减少IO损耗；
-
缓存查询结果(比如根据用户ID查询用户信息)
3. 中间件慢
-
redis慢：是否有热key、大key；
热key: 本地缓存
大key: 拆分大key或者采用set结构的sismember等方法判断-0(1)时间复杂度
-
kafka慢：
生产端慢：向kafka丢消息慢了，可以使用阻塞队列接收，批量发送消息等优化
消费端慢：扩分区、增加消费节点、增加消费线程或批量消费
4. 程序逻辑慢
-
非法校验逻辑前置，避免无用数据穿透消耗系统资源，减少无效调用;
-
循环调用改为单次调用，比如查数据库或查其他rpc或restful接口，能批量调用尽量批量调用，数据在内存组装处理；
-
同步调用改为异步调用 (采用CompletableFuture异步非阻塞，并行调用不同的rpc接口)；
Java异步任务编排—CompletableFuture（一） Java异步任务编排—CompletableFuture（二）
-
非核心逻辑剥离(拆分大事务，采用MQ异步解耦)；
-
线程池合理设置(千万不要创建无界队列线程池，线程池满了以后要重写拒绝策略，考虑告警加数据持久化)；
-
锁合理设置(本地读写锁设计不合理或锁力度太大、分布式锁合理使用防止热点key)；
-
优化gc参数(考虑young gcfull gc是否太频繁、调整c算法、新生代老年代比例)；
-
只打印必要日志(warn或error级别)
5. 架构优化
-
高并发读逻辑都走redis，尽可能不穿透到db；
-
涉及写逻辑数据(异步、批量处理、分库分表)；
-
接口接入限流熔断兜底(sentinel或hystrix)；
-
监控告警(error日志告警、接口慢查询或不可用告警，限流熔断告警、DB告警、中间件告警、应用系统告警)；
-
接口加动态配置开关快速切断流量或降级某一些非核心服务调用；
-
设计自动对账job，保证数据自动可修复；
网友评论