优化 API 的处理说明以及思路

前言

在 开发和维护 API 接口时候会存在部分接口存在性能问题，会影响服务稳定性， 本文希望可以可以朝着：“有效预防”， “快速止损” 有推进作用；

有效预防：针对自己的编写 API 有一份担当，规避常见雷区，从而引发灾难；
快速止损：当大家解决接口卡顿问题时候， 认清问题、解决方案上存在认知和效率等问题，基于这类场景我们撰写该文档，提供相关解决思路和处理方案，希望可以给大家一些帮助和指导作用；

知识库

常见雷区

1. 批次性质的业务逻辑代码放在数据库进行处理
2. 接口是事务的，但是存在使用 redis、API 调用的场景，需要考虑调用异常的场景（是选择最终的一致性，还是有回滚机制，还是不管不问）。

90分位、95分位接口响应耗时

90分位：采集了100个接口响应数据从小到大排序，然后取排在第90个接口的数据做为统计数据，95分位，同理。

90分位、95分位设计初心是为了避免长尾效应， 即避免少部分的过大值从平摊的维度上影响到平均响应这个值的变化，从而无法精准的定位问题，下方给出四种场景问题供大家思考下， 可以把每条数据视为 10%的数据去观察，若我们的报警是基于平均时间处理会分别出现什么问题？

XHProf 性能分析工具 （PHP）

相关安装指南：https://zhuanlan.zhihu.com/p/195106163
下载拓展入口： https://pecl.php.net/package/xhprof

windows 系统需要使用 wsl 或者 docker 进行部署项目， xhprof 不支持 windows 环境。

相关字段含义
Function Name 方法名称。
Calls 方法被调用的次数。
Calls% 方法调用次数在同级方法总数调用次数中所占的百分比。
Incl.Wall Time(microsec) 方法执行花费的时间，包括子方法的执行时间。（单位微秒）
IWall% 方法执行花费的时间百分比。
Excl. Wall Time(microsec) 方法本身执行花费的时间，不包括子方法的执行时间。（单位微秒）
EWall% 方法本身执行花费的时间百分比。
Incl. CPU(microsecs) 方法执行花费的CPU时间，包括子方法的执行时间。（单位微秒）
ICpu% 方法执行花费的CPU时间百分比。
Excl. CPU(microsec) 方法本身执行花费的CPU时间，不包括子方法的执行时间。（单位微秒）
ECPU% 方法本身执行花费的CPU时间百分比。
Incl.MemUse(bytes) 方法执行占用的内存，包括子方法执行占用的内存。（单位字节）
IMemUse% 方法执行占用的内存百分比。
Excl.MemUse(bytes) 方法本身执行占用的内存，不包括子方法执行占用的内存。（单位字节）
EMemUse% 方法本身执行占用的内存百分比。
Incl.PeakMemUse(bytes) Incl.MemUse峰值。（单位字节）
IPeakMemUse% Incl.MemUse峰值百分比。
Excl.PeakMemUse(bytes) Excl.MemUse峰值。单位字节
EPeakMemUse% Excl.MemUse峰值百分比。

Mysql Explain 对应介绍

Mysql 学习笔记： https://zhuanlan.zhihu.com/p/71232689
Explain 参数概念：https://juejin.cn/post/6847902221183483917

mysql> EXPLAIN SELECT * FROM event;
+—-+————-+——-+——+—————+——+———+——+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——+—————+——+———+——+——+——-+
| 1 | SIMPLE | event | ALL | NULL | NULL | NULL | NULL | 13 | |
+—-+————-+——-+——+—————+——+———+——+——+——-+
1 row in set (0.00 sec)

Binlog 同步
Mysql binlog 是二进制日志文件，用于记录 mysql 数据更新或者潜在更新(比如 DELETE 语句执行删除而实际并没有符合条件的数据)，在 mysql 主从复制中就是依靠的binlog。可以通过语句 show binlog events in ‘binlogfile’ 来查看 binlog 的具体事件类型；

使用场景：做缓存、做报表归纳、做事件驱动等；

使用说明：我们把 binlog 信息进行封装， 可以投递到 Kafka、rabbitMQ 这类的队列服务中，用于快捷的完成业务任务或者快速优化数据库造成卡顿的 API。

优化思路

第一步：确定问题（分析接口卡顿的组成条件）， 当我们被反馈1个接口响应慢的时候，此时我们需要先确定好导致该接口慢的组成条件以及使用场景，以便于复现场景和后续有效针对问题， 当下组成条件可从 “平均响应时间”、“90分位响应时间 ”、“95分位响应时间” 进行观看， 可以使用 Kibana 或者 Grafana 等查看数据看板进行分析。

第二步： 复现场景（构造请求条件数据）， 当我们确定接口卡顿组成条件后，调用线上日志获取对应参数在 预发布环境进行执行， 若存在非幂等操作，则需要自己构造数据；

第三步： 工具定位（使用产品化的工具帮助有效定位问题），例如使用 XHProf 性能分析工具分析相关接口， 点击 [View Full Callgraph] 进行下钻分析， 初始阶段建议处理 红色 / 黄色 , 而非一次性把所有卡顿的都进行解决，另外可以看到我们这次没有执行红色，因为这个是pdo操作，导致慢的是因为上面的sql查询（换句话来讲是可以确定是 sql 导致的卡顿），部分情况也可以自己打断点、自己记录log来分析；

第四步：代码分析, 发现是 SQL 导致的，则取出该 sql ， 在对应环境中 执行 explain 进行分析， 对应优化可由 dba 提供建议，若发现是递归函数则进行精简，若发现是请求 sql 次数过多，可以批量获取、批量插入， 若可以添加缓存则添加缓存（缓存需注意需不改变原逻辑同时 规避 缓存雪崩以及缓存穿透的问题），又或者进行异步处理；

第五步：制定方案，需要注意若无法直接解决可以去想解决80%的问题，而不是100%解决这个问题，选择性价比最高的而不是成本最大的方案才是我们优化的追求；

第六步：技术评审， 由 2- 3人研发一起确认该优化方案和结果过关，确定无风险，需要留下会议记录；

第七步：回归验收，对比结果集正常，以及对比效果提升效果，记录归纳；

第八步：上线检测，持续1 ~ 2个周的时间进行寻回检查确保没有问题后，完毕；