阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

教你三招从让性能从20s优化到500ms

81次阅读
没有评论

共计 5507 个字符,预计需要花费 14 分钟才能阅读完成。

导读 本文将会接着接口性能优化这个话题,从实战的角度出发,聊聊我是如何优化一个慢查询接口的。

教你三招从让性能从 20s 优化到 500ms

前言

接口性能问题,对于从事后端开发的同学来说,是一个绕不开的话题。想要优化一个接口的性能,需要从多个方面着手。

其实,我之前也写过一篇接口性能优化相关的文章《​​聊聊接口性能优化的 11 个小技巧​​》,发表之后在全网广受好评,感兴趣的小伙们可以仔细看看。

本文将会接着接口性能优化这个话题,从实战的角度出发,聊聊我是如何优化一个慢查询接口的。

上周我优化了一下线上的批量评分查询接口,将接口性能从最初的 20s​,优化到目前的 500ms 以内。

总体来说,用三招就搞定了。

到底经历了什么?

1. 案发现场

我们每天早上上班前,都会收到一封线上慢查询接口汇总邮件,邮件中会展示接口地址、调用次数、最大耗时、平均耗时和 traceId 等信息。

我看到其中有一个批量评分查询接口,最大耗时达到了 20s​,平均耗时也有 2s。

用 skywalking 查看该接口的调用信息,发现绝大数情况下,该接口响应还是比较快的,大部分情况都是 500s 左右就能返回,但也有少部分超过了 20s 的请求。

这个现象就非常奇怪了。

莫非跟数据有关?

比如:要查某一个组织的数据,是非常快的。但如果要查平台,即组织的根节点,这种情况下,需要查询的数据量非常大,接口响应就可能会非常慢。

但事实证明不是这个原因。

很快有个同事给出了答案。

他们在结算单列表页面中,批量请求了这个接口,但他传参的数据量非常大。

怎么回事呢?

当初说的需求是这个接口给分页的列表页面调用,每页大小有:10、20、30、50、100,用户可以选择。

换句话说,调用批量评价查询接口,一次性最多可以查询 100 条记录。

但实际情况是:结算单列表页面还包含了很多订单。基本上每一个结算单,都有多个订单。调用批量评价查询接口时,需要把结算单和订单的数据合并到一起。

这样导致的结果是:调用批量评价查询接口时,一次性传入的参数非常多,入参 list 中包含几百、甚至几千条数据都有可能。

2. 现状

如果一次性传入几百或者几千个 id,批量查询数据还好,可以走主键索引,查询效率也不至于太差。

但那个批量评分查询接口,逻辑不简单。

伪代码如下:

public List query(List list) {
// 结果
List result = Lists.newArrayList();
// 获取组织 id
List orgIds = list.stream().map(SearchEntity::getOrgId).collect(Collectors.toList());
// 通过 regin 调用远程接口获取组织信息
List 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 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 类创建线程池:

    @Configuration
    public 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。

    温馨提醒一下,无论是在批量查询评价接口查询数据库,还是在业务系统中调用批量查询评价接口,使用多线程调用,都只是一个临时方案,并不完美。

    这样做的原因主要是为了先快速解决问题,因为这种方案改动是最小的。

    要从根本上解决问题,需要重新设计这一套功能,需要修改表结构,甚至可能需要修改业务流程。但由于牵涉到多条业务线,多个业务系统,只能排期慢慢做了。

    阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年,有高配

    腾讯云新客低至 82 元 / 年,老客户 99 元 / 年

    代金券:在阿里云专用满减优惠券

    正文完
    星哥玩云-微信公众号
    post-qrcode
     0
    星锅
    版权声明:本站原创文章,由 星锅 于2024-07-25发表,共计5507字。
    转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
    【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
    阿里云-最新活动爆款每日限量供应
    评论(没有评论)
    验证码
    【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中