北京如何做网站网页,linx服务器怎么做网站,seo关键词查询工具,浏览器主页文章目录 一、背景二、接口优化方案总结1.批处理2.异步处理3.空间换时间4.预处理5.池化思想6.串行改并行7.索引8.避免大事务9.优化程序结构10.深分页问题11.SQL优化12.锁粒度避免过粗 三、最后 一、背景 针对老项目#xff0c;去年做了许多降本增效的事情#xff0c;其中发现… 文章目录 一、背景二、接口优化方案总结1.批处理2.异步处理3.空间换时间4.预处理5.池化思想6.串行改并行7.索引8.避免大事务9.优化程序结构10.深分页问题11.SQL优化12.锁粒度避免过粗 三、最后 一、背景 针对老项目去年做了许多降本增效的事情其中发现最多的就是接口耗时过长的问题就集中搞了一次接口性能优化。本文将给小伙伴们分享一下接口优化的通用方案。 二、接口优化方案总结 1.批处理 批量思想批量操作数据库这个很好理解我们在循环插入场景的接口中可以在批处理执行完成后一次性插入或更新数据库避免多次IO。 //批量入库 batchInsert();2.异步处理 异步思想针对耗时比较长且不是结果必须的逻辑我们可以考虑放到异步执行这样能降低接口耗时。 例如一个理财的申购接口入账 和写入申购文件 是同步执行的因为是T1交易后面这两个逻辑其实不是结果必须的我们并不需要关注它的实时结果所以我们考虑把入账 和写入申购文件 改为异步处理。如图所示 至于异步的实现方式可以用线程池也可以用消息队列还可以用一些调度任务框架。 3.空间换时间 一个很好理解的空间换时间 的例子是合理使用缓存针对一些频繁使用且不频繁变更的数据可以提前缓存起来需要时直接查缓存避免频繁地查询数据库或者重复计算。 需要注意的事这里用了合理二字因为空间换时间也是一把双刃剑需要综合考虑你的使用场景毕竟缓存带来的数据一致性问题也挺令人头疼。 这里的缓存可以是R2M也可以是本地缓存、memcached或者Map。 举一个股票工具的查询例子 因为策略轮动的调仓信息每周只更新一次所以原来的调接口就去查库的逻辑并不合理而且拿到调仓信息后需要经过复杂计算最终得出回测收益和跑赢沪深指数这些我们想要的结果。如果我们把查库操作和计算结果放入缓存可以节省很多的执行时间。如图 4.预处理 也就是预取思想就是提前要把查询的数据提前计算好放入缓存或者表中的某个字段用的时候会大幅提高接口性能。跟上面那个例子很像但是关注点不同。 举个简单的例子理财产品会有根据净值计算年化收益率的数据展示需求利用净值去套用年化收益率计算公式计算的逻辑我们可以采用预处理这样每一次接口调用直接取对应字段就可以了。 5.池化思想 我们都用过数据库连接池线程池等这就是池思想的体现它们解决的问题就是避免重复创建对象或创建连接可以重复利用避免不必要的损耗毕竟创建销毁也会占用时间。 池化思想包含但并不局限于以上两种总的来说池化思想的本质是预分配与循环使用 明白这个原理后我们即使是在做一些业务场景的需求时也可以利用起来。 比如对象池 6.串行改并行 串行就是当前执行逻辑必须等上一个执行逻辑结束之后才执行并行就是两个执行逻辑互不干扰所以并行相对来说就比较节省时间当然是建立在没有结果参数依赖的前提下。 比如理财的持仓信息展示接口我们既需要查询用户的账户信息也需要查询商品信息和banner位信息等等来渲染持仓页如果是串行基本上接口耗时就是累加的。如果是并行接口耗时将大大降低。 如图 7.索引 加索引能大大提高数据查询效率这个在接口设计之出也会考虑到这里不再多赘述随着需求的迭代我们重点整理一下索引不生效的一些场景希望对小伙伴们有所帮助。 具体不生效场景不再一一举例后面有时间的话单独整理一下。 8.避免大事务 所谓大事务问题就是运行时间较长的事务 由于事务一致不提交会导致数据库连接被占用影响到别的请求访问数据库影响别的接口性能。 举个例子 Transactional(value taskTransactionManager, propagation Propagation.REQUIRED, isolation Isolation.READ_COMMITTED, rollbackFor {RuntimeException.class, Exception.class}) public BasicResult purchaseRequest(PurchaseRecord record) {BasicResult result new BasicResult();...pushRpc.doPush(record); result.setInfo(ResultInfoEnum.SUCCESS);return result; }所以为避免大事务问题我们可以通过以下方案规避 1RPC调用不放到事务里面 2查询操作尽量放到事务之外 3事务中避免处理太多数据 9.优化程序结构 程序结构问题一般出现在多次需求迭代后代码叠加形成。会造成一些重复查询、多次创建对象等耗时问题。在多人维护一个项目时比较多见。解决起来也比较简单我们需要针对接口整体做重构评估每个代码块的作用和用途调整执行顺序。 10.深分页问题 深分页问题比较常见分页我们一般最先想到的就是 limit 为什么会慢我们可以看下这个SQL select * from purchase_record where productCode PA9044 and status4 and id 100000 limit 200这样优化的好处是命中了主键索引无论多少页性能都还不错但是局限性是需要一个连续自增的字段 11.SQL优化 sql优化能大幅提高接口的查询性能由于本文重点讲述接口优化的方案具体sql优化不再一一列举小伙伴们可以结合索引、分页、等关注点考虑优化方案。 12.锁粒度避免过粗 锁一般是为了在高并发场景下保护共享资源采用的一种手段但是如果锁的粒度太粗会很影响接口性能。 关于锁粒度就是你要锁的范围有多大不管是synchronized还是redis分布式锁只需要在临界资源处加锁即可不涉及共享资源的不必要加锁就好比你要上卫生间只需要把卫生间的门锁上就可以不需要把客厅的门也锁上。 错误的加锁方式 //非共享资源private void notShare(){}//共享资源private void share(){}private int right(){notShare();synchronized (this) {share();}}三、最后 接口性能问题形成的原因思考 我相信很多接口的效率问题不是一朝一夕形成的在需求迭代的过程中为了需求快速上线采取直接累加代码的方式去实现功能这样会造成以上这些接口性能问题。 变换思路更高一级思考问题站在接口设计者的角度去开发需求会避免很多这样的问题也是降本增效的一种行之有效的方式。