>关于优化API接口响应速度。。。 >今天只是粗略写写，关于这个优化设计的方面很多，接下来再仔细研究研究。 今天发现接口响应很慢，调开发者工具出来查看才发现接口居然耗时2秒左右，然后查了下后台逻辑，发现里面逻辑很多，有调用外部几个接口，还要查询数据库。 两个接口耗时都接近1.5秒了。看了下是查询工作流的接口，看来只能找平台部那边优化了。 剩下的就是优化我们这边系统的查询效率了。 首先需要分析为何慢了 1. 是不是资源层面的瓶颈？ 2. 是不是缓存没添加，如果加了，是不是热点数据导致负载不均衡？ 3. 是不是有依赖于第三方接口？ 4. 是不是接口涉及业务太多，导致程序跑很久？ 5. 是不是sql层面的问题导致的等待时机加长，进而拖慢接口？ 6. 网络层面的原因？带宽？DNS解析？ 7. 代码不行？ 8. 未知？ 对症下药 1. 资源紧张，加机器，干上去，负载均衡搞起来！ 2. 加缓存可以解决的问题都不是什么大问题，存在热点数据可以将某几个热点单独出来用专门的机器进行处理，不要因为局部影响整体（这一次好像不涉及这个） 3. 一方面与第三方沟通接口响应问题，另一方面超时时间注意把控，如果可以非核心业务能异步久异步掉。 4. 把非核心的业务进行异步化操作。记住如果代码层面是非核心业务，但是会影响用户感知，需要慎重决定是否异步。 5. 如果是代码不良导致加锁了，尽量优化索引或sql语句，让锁的级别最小（到行），一般来说到行差不多了。如果是单个sql跑慢了，需要分析是不是索引没加或者sql选的索引错了，索引该加的就加了，该force index也加了。 6. 网路原因，需要找运维人员，单方面比较难有大的优化。 7. 代码确实差，那也无药可救了。毁灭吧！ 刚开始以为是机器性能不行，看了下系统负载，发现占用率并不高，好像也不是性能问题。 接着以为是应用优化，但是看了下 JVM 的相关参数和 Java 堆的使用情况，发现都不高，感觉应该是数据库的原因了，当时建表的时候没有建相关的索引。 然后考虑加下索引试试。 加了一个组合索引，还有一个单列索引。 加了之前在代码中加了时间记录，感觉有所提升。 剩下的就是外部接口的耗时了。