记一次每日跑批任务耗时性能从六分钟优化到半分钟历程及总结

最新推荐文章于 2024-03-28 14:35:53 发布

秋夜无霜

最新推荐文章于 2024-03-28 14:35:53 发布

阅读量1.5k

点赞数

分类专栏： JavaWeb 文章标签： java 性能优化线程池

本文链接：https://blog.csdn.net/shichen2010/article/details/108156797

版权

JavaWeb 专栏收录该内容

55 篇文章 1 订阅

订阅专栏

话说做了一个产品需求上线后，涉及到有一个每日凌晨七点跑批任务，跑批查询出来的待处理订单也就1100单作用，但是耗时却花费了5~6分钟，虽说跑批中，又调用外部服务，但是仅仅在空闲时间，鉴于此情况
我觉得这个跑批任务有优化的空间，伴随着一次次性能优化，最终耗时优化到只需平均20多秒就跑批完毕，鉴于此，写一篇自己的优化过程分享给大家。

一、业务概述

话说我们产品需求有个每日凌晨七点，之所以为什么是定时，还要凌晨七点，那是由于在你跑批之前，中后台也有一步步跑批任务，只有等他们跑完任务，我们才能发起跑批调用，否则早的话，人家
的跑批任务没执行，你调用的时候只能是徒劳，这就是背景。话说，在最初技术方案调研时，通过微信电话本来想沟通一下，通过一些性能压测工具压测一下对方的接口性能，这样对于我们发起方也有
一个指标可以提供在技术实现中有所参考。但是呢，对方口述说，我们只是对决策平台，真正处理的是背后的数据引擎团队，他们的性能才是整个调用链路上的关键。想法很好，但最终没有压测。之所以这个情况，是由于对方的数据只在生产环境提供，测试环境没有。所以不太好压测，毕竟压测的时间点不一样，结论也不一样。毕竟他们提供很多业务方调用，既然如此，我想着先按照他提供的一些指标比如，秒级给出结果，不支持批量调用，只支持同步调用，不支持消息通知。这些结论使得我开始设计第一版技术方案，看看上线后的跑批耗时。

系统交互时序图

上面说了一大堆话，简言之概况如上图。中台的事情不做完，前台即便调度任务想要提前无济于事。所以在每天用户8、9点上班时，跑批任务就得生成工单。

二、上线版本

业务流程图

如上图，这是上线的第一个初步版本，第一次跑批1100多单，耗时了5~6分钟。当我告知给业务方，人家说，“不错了，还以为得跑半个小时”。然而，作为技术研发的我心中默默表示不甘心，觉得对这个跑批性能，认为有改善的空间，否则随处时间流逝，待处理订单会越来越多，前期不改善，后期肯定耗时越来越长。

第一版方案处理的过程如下

1、调度平台配置一个job，每天凌晨七点调度调用我这边的一个服务（线上部署两个节点，跑批固定IP一台服务器）（假设A），A服务提供一个rest接口，接口实现异步去执行后续处理订单。

rest接口示例如下：

@Autowired
ScanningOrderTask scanningOrderTask;

@PostMapping("/disposeOrders")
@ApiOperation(value = "待处理订单跑批", notes = "待处理订单跑批")
@NoAuthRequired
public SiaResponse disposeOrders() {
    scanningOrderTask.scanningOrder();
    return SiaResponse.newInstance("待处理订单跑批成功!");
}

ScanningOrderTask代码示例如下：

@Component
@Slf4j
public class ScanningOrderTask {

    @Autowired
    ExecutorService threadPoolExecutor;

    @Autowired
    DisposeOrderFacade disposeOrderFacade;

    /**
     * 订单跑谛听规则
     */
    public void scanningOrder(){
        log.info("##### [scanningOrder]待处理订单开始执行跑批处理 ####");
        CompletableFuture.runAsync(() -> disposeOrderFacade.scanningOrders(), threadPoolExecutor);
    }
}

2、disposeOrderFacade#scanningOrders提供的业务伪代码实现如下：

public void scanningOrders(){
    int start = 0;
    int limit = 100;
    StopWatch stopWatch = new StopWatch("scanningOrders");
    stopWatch.start();
    List<Object> disposeOrderList = 先查询第一页数据;
    do{
        List<DisposeOrder> repeatOrder = Lists.newArrayList();//二次重试需要再次重试订单
        for(DisposeOrder order : list){
            try{
                operateStrategyManager.execute(operateContext);
            }catch(Exception e){
                //异常重试
                operateStrategyManager.execute(operateContext);
                //再次重试失败，则加入失败订单
                if(再次重试失败){
                    repeatOrder(order);
                }
            }
        }
        //查询下一批 待扫描订单
        start += limit;
        param.setStart(start);
        disposeOrderList = disposeOrderService.queryByPage(param);
        if(CollectionUtils.isNotEmpty(repeatOrder)){
            disposeOrderList.addAll(repeatOrder);
        }
    }while(list非空)
    stopWatch.stop();
    int batchSize = longAdder.intValue() - errorOrderSet.size();
    long durationSeconds = (stopWatch.getLastTaskTimeMillis() / 1000);
    log.info("##### [scanningOrder]跑批处理完毕，共计={}单，耗时={}s ####",batchSize,durationSeconds);
}

3、决策引擎异步处理相关代码

public void operation(OperateContext context) {
    //1、调用决策引擎
    Result<AlarmDecisionRe> alarmDecisionResult = alarmDecisionManager.call(AlarmDecisionDTO.builder()
            .appCode(context.getDisposeOrder().getAppCode())
            .scenePhase(ScenePhaseEnum.LOAN_PROCESS.getIndex())
            .build());
    //2、决策输出的结果，再交由另外一个线程池 threadPoolExecutor（通用线程池）异步去处理。
    CompletableFuture.runAsync(() -> handleAlarmResult(alarmDecisionResult.getData()), threadPoolExecutor);
}

4、决策输出结果的异步处理相关代码

/**
 * 处理规则校验结果`
 * @param decisionResult
 */
void handleAlarmResult(AlarmDecisionRe decisionResult){
    String appCode = decisionResult.getAppCode();
    StopWatch stopWatch = new StopWatch("handleAlarmResult");
    stopWatch.start();
    if(Objects.isNull(decisionResult) || CollectionUtils.isEmpty(decisionResult.getDecisionRuleList())){
        log.info("[每日跑批]决策输出为空,appCode={}",appCode);
        return;
    }
    //存detail 优先级、编码
    AlarmDetail detail = AlarmDetail.builder()
            .appCode(appCode)
            .alarmTime(new Date())
            .alarmRules(JSON.toJSONString(decisionResult.getDecisionRuleList()))
            .scenePhase(ScenePhaseEnum.LOAN_PROCESS.getIndex())
            .build();
    alarmDetailService.insertRecord(detail);
    List<WorkOrder> oldWorkOrder = workOrderService.queryList(WorkOrderForm.builder()
            .appCode(decisionResult.getAppCode())
            .isFinished(ConstEnum.YesOrNoEnum.NO.getIndex()).build());
    if(CollectionUtils.isEmpty(oldWorkOrder)){
        saveWorkOrder(detail,decisionResult,0);
    }else{
        log.info("[每日跑批]该订单未处理完结无需创建,appCode={}",decisionResult.getAppCode());
    }
    stopWatch.stop();
    long duration = stopWatch.getLastTaskTimeMillis();
    log.info("[每日跑批]handleAlarmResult,appCode={},duration={}ms",appCode,duration);
}

综上所述，调度任务发起对A服务调用时，然后开启了一个异步任务去处理，异步任务中分页查询处理，循环处理每一个待处理订单，然后同步调用决策引擎，决策引擎返回的结果然后异步交由一个线程池去处理。跑批的待处理订单大概只有300多单会命中业务规则，对于命中规则的订单会生成工单外，还需要做相应一系列业务逻辑处理，包括通知调用其他系统业务处理。而未命中规则，仅需插入一个预警记录外。无需其他操作，这说明，整体耗时在这300多单阻塞同步循环调用决策引擎耗时占比非常大。

未命中决策规则

从上述图，可以看到命中决策规则的订单执行时间（跑批从凌晨七点执行，上图已经07:05分了），包括未命中决策规则的条数（763条）。

命中决策规则

从上述图，可以看到命中决策规则（这部分订单需要业务处理，包括以及Redis入队等操作）的订单执行时间，包括未命中决策规则的条数（362条）。

三、优化方案

基于上线第一版的结论分析，并尽可能不修改业务处理逻辑和程序逻辑处理下，通过引入下属方案处理。

优化版本业务处理示意图

从上图可以看到最明显与初版差异的是，这次优化方案是，把循环处理待处理订单的阻塞操作，改为异步处理，交由一个线程池去处理，串行等待变为并行处理。

disposeOrderFacade#scanningOrders的方法前后变化

//异步处理，把每个待处理订单放在disposeOrderHandleThreadPool（待处理线程池）去处理
CompletableFuture.runAsync(() -> operateStrategyManager.execute(operateContext), disposeOrderHandleThreadPool);

/**
 * @description: 线程池配置
 * @Date : 2019/4/25 下午2:36
 * @Author : 石冬冬-Seig Heil
 */
@Configuration
@EnableAsync
@Slf4j
public class ThreadPoolConfig {

    static final int blockingQueueCapacity = 5000;

    static final int keepAliveTime = 60;

    static final int availableProcessors = Runtime.getRuntime().availableProcessors();

    static final int corePoolSize  = availableProcessors * 8;

    static final int maximumPoolSize = 50;

    static {
        log.info("[availableProcessors]={},corePoolSize={},maximumPoolSize={}",availableProcessors,corePoolSize,maximumPoolSize);
    }

    /**
     * 通用线程池配置
     * @return
     */
    @Bean
    public ExecutorService threadPoolExecutor() {
        ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("common-pool-%d").build();
        return new ThreadPoolExecutor(corePoolSize,maximumPoolSize,keepAliveTime, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(blockingQueueCapacity), threadFactory);
    }

    /**
     * 跑批待处理订单线程池配置
     * blockingQueueCapacity 需要设置合理大小，目前上线一周，每日跑批 1175单左右；即便线程池已满，使用拒绝策略；有补偿机制。
     * @return
     */
    @Bean
    public ExecutorService disposeOrderHandleThreadPool() {
        ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("disposeOrder-pool-%d").build();
        final int corePoolSize = availableProcessors * 6,maxPoolSize = corePoolSize * 2,keepAliveTime = 60,blockingQueueCapacity = 5000;
        return new ThreadPoolExecutor(corePoolSize,maxPoolSize,keepAliveTime, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(blockingQueueCapacity), threadFactory);
    }

}

这是上述线程池配置，也是目前跑到线上的配置。其中 disposeOrderHandleThreadPool （待处理订单线程池）也是经过几次优化后最终设置的参数配置。

第一次优化，出现队列拒绝现象。

/**
 * 跑批待处理订单线程池配置
 * @return
 */
@Bean
public ExecutorService disposeOrderHandleThreadPool() {
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("carthage-disposeOrder-pool-%d").build();
    final int corePoolSize = 5,maxPoolSize = 12;
    return new ThreadPoolExecutor(corePoolSize,maxPoolSize,60, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(500), threadFactory);
}

线程池配置如上，核心线程数5个，最大线程数10个，队列长度500个。

异常信息如下所图(好在待处理有重试机制，跑批任务数据没有问题)：

异常信息

第二次优化，无队列拒绝现象。

/**
 * 跑批待处理订单线程池配置
 * blockingQueueCapacity 需要设置合理大小，目前上线一周，每日跑批 1175单左右；即便线程池已满，使用拒绝策略；有补偿机制。
 * @return
 */
@Bean
public ExecutorService disposeOrderHandleThreadPool() {
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("carthage-disposeOrder-pool-%d").build();
    final int corePoolSize = availableProcessors * 4,maxPoolSize = corePoolSize,keepAliveTime = 60,blockingQueueCapacity = 5000;
    return new ThreadPoolExecutor(corePoolSize,maxPoolSize,keepAliveTime, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(blockingQueueCapacity), threadFactory);
}

线程池配置如上，核心线程数14个（线上容器处理器核数4核），最大线程数跟核心一致16个，队列长度5000个。

跑批情况（共计=1210单，主线程：耗时=1s；子线程最后一单最后完成时间 2020-08-16 07:00:27.794；），跑批任务正常，无线程任务队列拒绝现象。

异常信息

如上图，跑批任务最后一单执行日志输出，整个跑批耗时花费26秒。这是在一次周末抽空优化的结果。

第三次优化，进一步调整待处理和通用线程池核心数大小。

static final int blockingQueueCapacity = 5000;

static final int keepAliveTime = 60;

static final int availableProcessors = Runtime.getRuntime().availableProcessors();

static final int corePoolSize  = availableProcessors * 8;

static final int maximumPoolSize = 50;
    
/**
 * 通用线程池配置
 * @return
 */
@Bean
public ExecutorService threadPoolExecutor() {
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("common-pool-%d").build();
    return new ThreadPoolExecutor(corePoolSize,maximumPoolSize,keepAliveTime, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(blockingQueueCapacity), threadFactory);
}
    
/**
 * 跑批待处理订单线程池配置
 * blockingQueueCapacity 需要设置合理大小，目前上线一周，每日跑批 1175单左右；即便线程池已满，使用拒绝策略；有补偿机制。
 * @return
 */
@Bean
public ExecutorService disposeOrderHandleThreadPool() {
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("disposeOrder-pool-%d").build();
    final int corePoolSize = availableProcessors * 6,maxPoolSize = corePoolSize * 2,keepAliveTime = 60,blockingQueueCapacity = 5000;
    return new ThreadPoolExecutor(corePoolSize,maxPoolSize,keepAliveTime, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(blockingQueueCapacity), threadFactory);
}

通用线程池核心数32，最大50，队列长度500；待处理订单线程池配置核心数24，最大48，队列长度5000。

目前今日跑批（8月21日）1323单，主线程耗时=1s；子线程最后一单完成时间（2020-08-21 07:00:22.040），仅需要22秒，三次优化从最初5~6分钟，到现在的单机跑批22秒，质的飞跃。

CPU以及堆内存使用情况

上图是今日（8月21日）跑批容器实例（单机）的CPU以及堆内存使用情况。

CPU以及线程数

上图是今日（8月21日）跑批容器实例（单机）的CPU以及线程数。
堆内存和GC情况

上图是今日（8月21日）跑批容器实例（单机）的堆内存和GC情况（JDK8，使用G1垃圾收集器，跑批期间发生一次MGC）。

四、归纳总结

1、性能优化尽量如果上线后，尽量在少修改业务代码或程序逻辑前提下，逐步改善方案。
2、串行变并行，使用线程池去处理，合理逐步调整线程池核心数以及队列长度。
3、线程池根据不同业务场景，应用不要采用一个线程池处理所有异步任务场景。
4、代码中通过合理打印日志，便于后期排查问题以及优化提供帮助。

下面的是我的公众号二维码图片，欢迎关注，或公众号搜索【秋夜无霜】。

秋夜无霜

关注

0
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
记一次每日跑批任务耗时性能从六分钟优化到半分钟历程及总结

话说做了一个产品需求上线后，涉及到有一个每日凌晨七点跑批任务，跑批查询出来的待处理订单也就1100单作用，但是耗时却花费了5~6分钟，虽说跑批中，又调用外部服务，但是仅仅在空闲时间，鉴于此情况我觉得这个跑批任务有优化的空间，伴随着一次次性能优化，最终耗时优化到只需平均20多秒就跑批完毕，鉴于此，写一篇自己的优化过程分享给大家。一、业务概述话说我们产品需求有个每日凌晨七点，之所以为什么是定时，还要凌晨七点，那是由于在你跑批之前，中后台也有一步步跑批任务，只有等他们跑完任务，我们才能发起跑批调用，否.
复制链接

扫一扫