接口优化从哪些方面入手？

关注公众号【1024个为什么】，及时接收最新推送文章！

1、背景

新接手的一个服务，对整个服务熟悉后，发现调用量 TOP1 的一个接口，完全超乎我对这个接口使用场景的预期，预期几万的接口，实际调用量近 400万，和调用方交涉后，暂时无法推动调用方优化，所以只能从接口内部优化。

2、存在的问题

2.1 不合理的重复调用

同一调用链内，连续调用3次

貌似还有定时任务10分钟一次

2.2 日志文件过大，浪费磁盘空间且不利于排查问题

24G，一个下游且相对边缘的服务，单节点的日志竟然 24G，除上游不合理的调用量外，肯定有日志打印不当的地方。

排查问题时搜索到关键字要几十秒，严重影响到问题排查。

2.3 接口平均耗时高

平均耗时 11.5ms，其实内部调用逻辑很简单，就是数据库查询、redis、RPC调用，按调用链路预估 6ms 左右就正常。

2.4 冗余的数据库调用

接口内 18 次数据库调用中，很多是冗余的，可以优化或者减少调用。

2.5 缓存使用不当

redis 调用 8 次，有6次都是重复调用；

缓存内容不合理，缓存了很多无用内容，无需缓存的也用了缓存

3、从哪里入手？

3.1 减少数据库调用、低效查询

1）有一个 2 次单表组合查询的逻辑，接口中总共会调用 3 次。

select * from A where id=?; // 其中包含 B.id
select * from B where id=?;

把 B 中的 amount，覆盖掉 A 中的 amount，返回。

优化为联表查询，都会走主键索引，少一次数据库查询。

2）3 次调用中，最后一次查询是重复的，在第二次查询处理后已经返回了最新的数据，去掉这次查询，直接把第二次返回的数据给第三次查询后的逻辑使用，减少一次数据库查询。

3）有一次提前的无用的数据库查询，查询结果只在后续逻辑特定条件分支才会用到，概率极低，绝大多数会提前返回结果。把这次查询后移到真正使用处，减少一次数据库查询。

3.2 减少 redis 调用

有一个场景，从根据品类ID从缓存获取归属业务线ID的，实际只会有 3 个品类ID，映射出 2 个业务线ID，完全没必要走缓存，直接改为写死返回，可以减少 6 次 redis 调用。

3.3 修改不合理缓存

有一个缓存商家标签的缓存，会缓存标签集合的所有属性，而逻辑中只需要用到标签ID，改为只缓存标签ID，缓存内容减少为原来的 0.8%，节省 redis 缓存，减少网络耗时。

3.4 增加接口缓存

前面提到调用方存在不合理的调用，一次调用链中，连续多次调用，几次的入参、结果都相同，所以没必要每次都走一遍接口逻辑。

对接口层面加缓存，后面几次的访问直接从缓存获取。

由于接口返回内容仅有 200 个字符左右，缓存时间为 2 秒，QPS 为 50 左右，占用缓存空间很小 30K 左右。

3.5 减少不合理的日志

梳理发现，有很多不合理的日志，总结为以下几点：

1）直接把全量集合内容直接打印出来

改为只打印 size，或者只打印关键ID。

2）DAO层冗余的日志

每行日志除了我们要打印的信息外，还有额外的信息，例如时间、日志级别、调用链、当前位置 等等。

对于实际日志内容很短的场景，很不划算，把 2 行改为 1 行，可以减少很多日志输出。

原则是既不影响排查问题，又不多打无用的日志。

3）低效的日志

正如上图所示，要打印的对象，一律都加了 JSON.toJSONString()，json 框架内部会有很长的调用逻辑，严重影响性能。

删除String 以及基础数据类型的 toJSONString 的转换。

4、效果

优化前耗时：

优化后耗时：

日志大小：

从 24G 减少到 4 G。

5、总结

我的格局很小，

会抠每一行日志，

会抠整个调用链路上有无重复的查询，

会抠是否需要缓存，

会抠缓存的内容是否都是必要内容，

会抠每一次 rpc 调用是否必要，是否可以缓存。

扯两句

你的问题背景肯定和我的不一样，但可以参考我的思路，死抠每一行代码。

我始终相信，每一个细节都把控好了，就不可能有低效的接口。

原创不易，多多关注，一键三连，感谢支持！