记一次接口性能优化实践总结：优化接口性能的八个建议
前言
最近对外接口偶现504超时问题，缘由是代码执行时间过长，超过nginx配置的15秒，而后真枪实弹搞了一次接口性能优化。在这里结合优化过程，总结了接口优化的八个要点，但愿对你们有帮助呀~nginx
数据量比较大，批量操做数据入库git
耗时操做考虑异步处理程序员
恰当使用缓存github
优化程序逻辑、代码sql
SQL优化数据库
压缩传输内容后端
考虑使用文件/MQ等其余方式暂存，异步再落地DB缓存
跟产品讨论需求最恰当，最舒服的实现方式性能优化
嘻嘻，先看一下咱们对外转帐接口的大概流程吧并发
1.数据量比较大，批量操做数据入库
优化前：
优化后：
性能对比：
批量插入性能更好，更加省时间，为何呢？
打个比喻:假如你须要搬一万块砖到楼顶,你有一个电梯,电梯一次能够放适量的砖（最多放500）,你能够选择一次运送一块砖,也能够一次运送500,你以为哪一种方式更方便，时间消耗更少?
2.耗时操做考虑异步处理
耗时操做，考虑用异步处理，这样能够下降接口耗时。本次转帐接口优化，匹配联行号的操做耗时有点长，因此优化过程把它移到异步处理了，以下：
优化前：
优化后
匹配联行号的操做异步处理
性能对比：
假设一个联行号匹配6ms
解析：
由于联行号匹配比较耗时，放在异步处理的话，同步联机返回能够省掉这部分时间，大大提高接口性能，而且不会影响到转帐主流程功能。
除了这个例子，平时咱们相似功能，如用户注册成功后，短信邮件通知，也是能够异步处理的，这个优化建议香饽饽的~
因此，太耗时的操做，在不影响主流程功能的状况下，能够考虑开子线程异步处理的啦。
3.恰当使用缓存
在适当的业务场景，恰当地使用缓存，是能够大大提升接口性能的。这里的缓存包括：Redis，JVM本地缓存，memcached，或者Map等。
此次转帐接口，使用到缓存啦，举个简单例子吧~
优化前
如下是输入用户帐号，匹配联行号的流程图
优化后：
恰当使用缓存，代替查询DB表，流程图以下：
解析：
把热点数据放到缓存，不用每次查询都去DB拉取，节省了这部分查SQL的耗时，美滋滋呀~
固然，不是什么数据都适合放到缓存的哦，访问比较频繁的热点数据才考虑缓存起来呢~
4. 优化程序逻辑、代码
优化程序逻辑、程序代码，是能够节省耗时的。
我这里就本次的转帐接口优化，举个例子吧~
优化前：
优化前，联行号查询了两次（检验参数一次，插入DB前查询一次），以下伪代码：
优化后：
优化后，只在校验参数的时候插叙一次，而后设置到对象里面~ 入库前就不用再查啦，伪代码以下：
解析：
对于优化程序逻辑、代码，是能够下降接口耗时的。以上demo只是一个很简单的例子，就是优化前payeeBankNo查询了两次，可是其实只查一次就能够了。不少时候，咱们都知道这个点，但就是到写代码的时候，又忘记了呀~因此，写代码的时候，留点心吧，优化你的程序逻辑、代码哦。
除了以上demo这点，还有其它特色，如优化if复杂的逻辑条件，考虑是否能够调整顺序，或者for循环，是否重复实例化对象等等，这些适当优化，都是可让你的代码跑得更快的。
以前我这篇文章，也提了几个优化点噢，有兴趣的朋友能够看一下哈~
写代码有这些想法，同事才不会认为你是复制粘贴程序员
5. 优化你的SQL
不少时候，你的接口性能瓶颈就在SQL这里，慢查询须要咱们重点关注的点呢。
咱们能够经过这些方式优化咱们的SQL：
加索引
避免返回没必要要的数据
优化sql结构
分库分表
读写分离
有兴趣的朋友能够看一下我这篇文章呢，很详细的SQL优化点：
后端程序员必备：书写高质量SQL的30条建议
6.压缩传输内容
压缩传输内容，文件变得更小，所以传输会更快啦。10M带宽，传输10k的报文，通常比传输1M的会快呀；打个比喻，一匹千里马，它驮着一百斤的货跑得快，仍是驮着10斤的货物跑得快呢？
解析：
若是你的接口性能很差，而后传输报文比较大的话，这时候是能够考虑压缩文件内容传输的，最后优化效果可能很不错哦~
7. 考虑使用文件/MQ等其余方式暂存数据，异步再落地DB
若是数据太大，落地数据库实在是慢的话，能够考虑先用文件的方式保存，或者考虑MQ，先落地，再异步保存到数据库~
本次转帐接口，若是是并发开启，10个并发度，每一个批次1000笔数据，数据库插入会特别耗时，大概10秒左右，这个跟咱们公司的数据库同步机制有关，并发状况下，由于优先保证同步，因此并行的插入变成串行啦，就很耗时。
优化前：
优化前，1000笔先落地DB数据库，再异步转帐，以下：
优化后：
先保存数据到文件，再异步下载下来，插入数据库，以下：
解析：
若是你的耗时瓶颈就在数据库插入操做这里了，那就考虑文件保存或者MQ或者其余方式暂存吧，文件保存数据，对比一下耗时，有时候会有意想不到的效果哦。
8.跟产品讨论需求最恰当，最舒服的实现方式
这点我的以为仍是很重要的，有些需求须要好好跟产品沟通的。
好比有个用户连麦列表展现的需求，产品说要展现全部的连麦信息，若是一个用户的连麦列表信息好大，你拉取全部连麦数据回来，接口性能就降下来了。若是产品打桩分析，会发现，通常用户看连麦列表，也就看前几页~所以，奸笑，哈哈~ 其实，那个超大分页加载问题也是相似的。即limit +一个超大的数，通常会很慢的~~
总结
本文呢，基于一次对外接口耗时优化的实践，总结了优化接口性能的八个点，但愿对你们平常开发有帮助哦~嘻嘻，有兴趣能够逛逛个人github哈，本文会收藏到github里滴哈
https://github.com/whx123/JavaHome