接口优化的常见方案实战总结

目录

前言：

一、背景

二、接口优化方案总结

1.批处理

2.异步处理

3.空间换时间

4.预处理

5.池化思想

6.串行改并行

7.索引

8.避免大事务

9.优化程序结构

10.深分页问题

11.SQL 优化

12.锁粒度避免过粗

---

前言：

接口优化是提高系统性能和响应速度的重要环节。在实战中，有几种常见的方案可以用来优化接口性能。

一、背景

针对老项目，去年做了许多降本增效的事情，其中发现最多的就是接口耗时过长的问题，就集中搞了一次接口性能优化。本文将给小伙伴们分享一下接口优化的通用方案。

二、接口优化方案总结

1.批处理

批量思想：批量操作数据库，这个很好理解，我们在循环插入场景的接口中，可以在批处理执行完成后一次性插入或更新数据库，避免多次 IO。

//for循环单笔入库
list.stream().forEatch(msg->{
    insert();
});

//批量入库
batchInsert();

2.异步处理

异步思想：针对耗时比较长且不是结果必须的逻辑，我们可以考虑放到异步执行，这样能降低接口耗时。

例如一个理财的申购接口，入账和写入申购文件是同步执行的，因为是 T+1 交易，后面这两个逻辑其实不是结果必须的，我们并不需要关注它的实时结果，所以我们考虑把入账和写入申购文件改为异步处理。如图所示：

至于异步的实现方式，可以用线程池，也可以用消息队列，还可以用一些调度任务框架。

3.空间换时间

一个很好理解的空间换时间的例子是合理使用缓存，针对一些频繁使用且不频繁变更的数据，可以提前缓存起来，需要时直接查缓存，避免频繁地查询数据库或者重复计算。

需要注意的事，这里用了合理二字，因为空间换时间也是一把双刃剑，需要综合考虑你的使用场景，毕竟缓存带来的数据一致性问题也挺令人头疼。

这里的缓存可以是 R2M，也可以是本地缓存、memcached，或者 Map。

举一个股票工具的查询例子：

因为策略轮动的调仓信息，每周只更新一次，所以原来的调接口就去查库的逻辑并不合理，而且拿到调仓信息后，需要经过复杂计算，最终得出回测收益和跑赢沪深指数这些我们想要的结果。如果我们把查库操作和计算结果放入缓存，可以节省很多的执行时间。如图：