前言
接口性能问题，对于从事后端开发的同学来说，是一个绕不开的话题。想要优化一个接口的性能，须要从多个方面着手。
本文将会接着接口性能优化这个话题，从实战的角度登程，聊聊我是如何优化一个慢查问接口的。
上周我优化了一下线上的批量评分查问接口，将接口性能从最后的20s，优化到目前的500ms以内。
总体来说，用三招就搞定了。到底经验了什么？
1. 案发现场
咱们每天早上下班前，都会收到一封线上查问接口汇总邮件，邮件中会展现接口地址、调用次数、最大耗时、均匀耗时和traceId等信息。
我看到其中有一个批量评分查问接口，最大耗时达到了20s，均匀耗时也有2s。
用skywalking查看该接口的调用信息，发现绝大数状况下，该接口响应还是比拟快的，大部分状况都是500s左右就能返回，但也有少部分超过了20s的申请。
这个景象就十分奇怪了。
莫非跟数据无关？
比方：要查某一个组织的数据，是十分快的。但如果要查平台，即组织的根节点，这种状况下，须要查问的数据量十分大，接口响应就可能会十分慢。
但事实证明不是这个起因。
很快有个共事给出了答案。
他们在结算单列表页面中，批量申请了这个接口，但他传参的数据量十分大。
怎么回事呢？
当初说的需要是这个接口给分页的列表页面调用，每页大小有：10、20、30、50、100，用户能够抉择。
换句话说，调用批量评估查问接口，一次性最多能够查问100条记录。
但理论状况是：结算单列表页面还蕴含了很多订单。基本上每一个结算单，都有多个订单。调用批量评估查问接口时，须要把结算单和订单的数据合并到一起。
这样导致的后果是：调用批量评估查问接口时，一次性传入的参数十分多，入参list中蕴含几百、甚至几千条数据都有可能。
2. 现状
如果一次性传入几百或者几千个id，批量查问数据还好，能够走主键索引，查问效率也不至于太差。
但那个批量评分查问接口，逻辑不简略。
伪代码如下：
public List<ScoreEntity> query(List<SearchEntity> list) { //后果 List<ScoreEntity> result = Lists.newArrayList(); //获取组织id List<Long> orgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList()); //通过regin调用近程接口获取组织信息 List<OrgEntity> orgList = feginClient.getOrgByIds(orgIds); for(SearchEntity entity : list) { //通过组织id找组织code String orgCode = findOrgCode(orgList, entity.getOrgId()); //通过组合条件查问评估 ScoreSearchEntity scoreSearchEntity = new ScoreSearchEntity(); scoreSearchEntity.setOrgCode(orgCode); scoreSearchEntity.setCategoryId(entity.getCategoryId()); scoreSearchEntity.setBusinessId(entity.getBusinessId()); scoreSearchEntity.setBusinessType(entity.getBusinessType()); List<ScoreEntity> resultList = scoreMapper.queryScore(scoreSearchEntity); if(CollectionUtils.isNotEmpty(resultList)) { ScoreEntity scoreEntity = resultList.get(0); result.add(scoreEntity); } } return result;}其实在实在场景中，代码比这个简单很多，这里为了给大家演示，简化了一下。
最要害的中央有两点：
在接口中近程调用了另外一个接口
须要在for循环中查问数据
其中的第1点，就是：在接口中近程调用了另外一个接口，这个代码是必须的。
因为如果在评估表中冗余一个组织code字段，万一哪天组织表中的组织code有批改，不得不通过某种机制，告诉咱们同步批改评估表的组织code，不然就会呈现数据不统一的问题。
很显然，如果要这样调整的话，业务流程上要改了，代码改变有点大。
所以，还是先放弃在接口中近程调用吧。
这样看来，能够优化的中央只能在：for循环中查问数据。
3. 第一次优化
因为须要在for循环中，每条记录都要依据不同的条件，查问出想要的数据。
因为业务零碎调用这个接口时，没有传id，不好在where条件中用id in (...)，这形式批量查问数据。
其实，有一种方法不必循环查问，一条sql就能搞定需要：应用or关键字拼接，例如：(org_code='001' and category_id=123 and business_id=111 and business_type=1) or(org_code='002' and category_id=123 and business_id=112 and business_type=2) or(org_code='003' and category_id=124 and business_id=117 and business_type=1)...
这种形式会导致sql语句会十分长，性能也会很差。
其实还有一种写法：
where (a,b) in ((1,2),(1,3)...)不过这种sql，如果一次性查问的数据量太多的话，性能也不太好。
竟然没法改成批量查问，就只能优化单条查问sql的执行效率了。
首先从索引动手，因为革新老本最低。
第一次优化是优化索引。
评估表之前建设一个business_id字段的一般索引，然而从目前来看效率不太现实。
因为咱们果决加了联结索引：
alter table user_score add index `un_org_category_business` (`org_code`,`category_id`,`business_id`,`business_type`) USING BTREE;该联结索引由：org_code、category_id、business_id和business_type四个字段组成。
通过这次优化，成果空谷传声。
批量评估查问接口最大耗时，从最后的20s，缩短到了5s左右。
4. 第二次优化
因为须要在for循环中，每条记录都要依据不同的条件，查问出想要的数据。
只在一个线程中查问数据，显然太慢。
那么，为何不能改成多线程调用？
第二次优化，查询数据库由单线程改成多线程。
但因为该接口是要将查问出的所有数据，都返回回去的，所以要获取查问后果。
应用多线程调用，并且要获取返回值，这种场景应用java8中的CompleteFuture十分适合。
代码调整为：
CompletableFuture[] futureArray = dataList.stream() .map(data -> CompletableFuture .supplyAsync(() -> query(data), asyncExecutor) .whenComplete((result, th) -> { })).toArray(CompletableFuture[]::new);CompletableFuture.allOf(futureArray).join();CompleteFuture的实质是创立线程执行，为了防止产生太多的线程，所以应用线程池是十分有必要的。
优先举荐应用ThreadPoolExecutor类，咱们自定义线程池。
具体代码如下：
ExecutorService threadPool = new ThreadPoolExecutor( 8, //corePoolSize线程池中外围线程数 10, //maximumPoolSize 线程池中最大线程数 60, //线程池中线程的最大闲暇工夫，超过这个工夫闲暇线程将被回收 TimeUnit.SECONDS,//工夫单位 new ArrayBlockingQueue(500), //队列 new ThreadPoolExecutor.CallerRunsPolicy()); //回绝策略也能够应用ThreadPoolTaskExecutor类创立线程池：
@Configurationpublic class ThreadPoolConfig { /** * 外围线程数量，默认1 */ private int corePoolSize = 8; /** * 最大线程数量，默认Integer.MAX_VALUE; */ private int maxPoolSize = 10; /** * 闲暇线程存活工夫 */ private int keepAliveSeconds = 60; /** * 线程阻塞队列容量,默认Integer.MAX_VALUE */ private int queueCapacity = 1; /** * 是否容许外围线程超时 */ private boolean allowCoreThreadTimeOut = false; @Bean("asyncExecutor") public Executor asyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(corePoolSize); executor.setMaxPoolSize(maxPoolSize); executor.setQueueCapacity(queueCapacity); executor.setKeepAliveSeconds(keepAliveSeconds); executor.setAllowCoreThreadTimeOut(allowCoreThreadTimeOut); // 设置回绝策略，间接在execute办法的调用线程中运行被回绝的工作 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 执行初始化 executor.initialize(); return executor; }}通过这次优化，接口性能也晋升了5倍。
从5s左右，缩短到1s左右。
但整体成果还不太现实。
5. 第三次优化
通过后面的两次优化，批量查问评估接口性能有一些晋升，但耗时还是大于1s。
呈现这个问题的根本原因是：一次性查问的数据太多。
那么，咱们为什么不限度一下，每次查问的记录条数呢？
第三次优化，限度一次性查问的记录条数。其实之前也做了限度，不过最大是2000条记录，从目前看成果不好。
限度该接口一次只能查200条记录，如果超过200条则会报错提醒。
如果间接对该接口做限度，则可能会导致业务零碎出现异常。
为了防止这种状况的产生，必须跟业务零碎团队一起讨论一下优化计划。
次要有上面两个计划：
5.1 前端做分页
在结算单列表页中，每个结算单默认只展现1个订单，多余的分页查问。
这样的话，如果依照每页最大100条记录计算的话，结算单和订单最多一次只能查问200条记录。
这就须要业务零碎的前端做分页性能，同时后端接口要调整反对分页查问。
但目前现状是前端没有多余开发资源。
因为人手不足的起因，这套计划目前只能临时搁置。
5.2 分批调用接口
业务零碎后端之前是一次性调用评估查问接口，当初改成分批调用。
比方：之前查问500条记录，业务零碎只调用一次查问接口。
当初改成业务零碎每次只查100条记录，分5批调用，总共也是查问500条记录。
这样不是变慢了吗？
答：如果那5批调用评估查问接口的操作，是在for循环中单线程程序的，整体耗时当然可能会变慢。
但业务零碎也能够改成多线程调用，只需最终汇总后果即可。
此时，有人可能会问题：在评估查问接口的服务器多线程调用，跟在其余业务零碎中多线程调用不是一回事？
还不如把批量评估查问接口的服务器中，线程池的最大线程数调大一点？
显然你疏忽了一件事：线上利用个别不会被部署成单点。绝大多数状况下，为了防止因为服务器挂了，造成单点故障，根本会部署至多2个节点。这样即便一个节点挂了，整个利用也能失常拜访。
当然也可能会呈现这种状况：如果挂了一个节点，另外一个节点可能因为拜访的流量太大了，扛不住压力，也可能因而挂掉。
换句话说，通过业务零碎中的多线程调用接口，能够将拜访接口的流量负载平衡到不同的节点上。
他们也用8个线程，将数据分批，每批100条记录，最初将后果汇总。
通过这次优化，接口性能再次晋升了1倍。
从1s左右，缩短到小于500ms。
舒适揭示一下，无论是在批量查问评估接口查询数据库，还是在业务零碎中调用批量查问评估接口，应用多线程调用，都只是一个长期计划，并不完满。
这样做的起因次要是为了先疾速解决问题，因为这种计划改变是最小的。
要从根本上解决问题，须要从新设计这一套性能，须要批改表构造，甚至可能须要批改业务流程。但因为牵涉到多条业务线，多个业务零碎，只能排期缓缓做了。