CN116974730B - 一种大批量任务处理方法 - Google Patents

Abstract

本发明公开了一种大批量任务处理方法，属于计算机应用技术领域，该方法包括：S1，业务系统定义任务处理者类，并绑定任务类型；S2，任务中心组件扫描任务处理者类，建立任务类型和任务处理者类的映射关系；S3，业务系统向任务中心组件发起批量任务请求；S4，任务中心组件接收任务，将任务信息添加到Redis队列头部；S5，定时任务从Redis队列的队尾循环取任务提交到线程池，当线程池饱和时退出本次循环；S6，工作线程执行任务并记录任务执行结果；S7，服务器重启或停止时，守护线程将未执行的任务添加到Redis队列的尾部。该方案支持大批量任务，降低了服务器的压力，保障了系统的稳定性，通用性和扩展性强，可追溯性强。

Description

一种大批量任务处理方法

技术领域

本发明涉及计算机应用技术领域，尤其涉及一种大批量任务处理方法。

背景技术

在企业级应用中，经常会有类似“平台要搞活动，发送活动提醒短信给符合条件的几十万用户”这类大批量任务处理的需求，在处理这类需求时，要从性能、耦合度、稳定性等维度去设计技术实现方案。

目前普遍的处理方式及各方式的优缺点如下所示：

1、调用者同步去处理任务。优点：一步一步完成，确保了每一步结果的正确性。缺点：性能低、耦合度高。

2、每来一个任务，创建异步线程去执行。优点：提高性能、解耦。缺点：线程无法控制，若线程过多，会增加服务器资源消耗、降低系统稳定性。

3、使用线程池，将任务丢入池中，异步执行。优点：提高性能、解耦、控制并发数，防止服务器资源过度消耗和系统崩溃。缺点：在服务重启时，线程池中未执行的任务会丢失，且不方便处理大批量的任务。

4、将任务丢入消息队列（如RocketMQ），消费者异步执行。优点：提高性能、解耦、支持大批量任务、系统重启任务数据不丢失。缺点：压力落在消费者服务上，增加消费者服务器资源消耗、降低服务器其他能力。

发明内容

本发明要解决的技术问题是：针对现有技术的上述弊端，提供一种大批量任务处理方法，在保证性能、降低解耦、支持大批量任务、系统重启任务不丢失的前提下，降低任务处理时服务器的压力，保障系统稳定性。

为实现上述目的，本发明提供了一种大批量任务处理方法，包括以下步骤：

S1，各业务系统定义任务处理者类，并为每个任务处理者类绑定任务类型；

S2，任务中心组件初始化时，扫描任务处理者类，建立任务类型和任务处理者类的映射关系；

S3，各业务系统向任务中心组件发起批量任务请求，任务信息包含任务类型、自定义扩展参数；

S4，任务中心组件接收任务，将批量任务请求信息转JSON序列化后添加到RedisList等待队列头部；

S5，定时任务在定时触发时，从Redis List等待队列的队尾循环取任务提交到线程池，当线程池饱和时退出本次循环；

S6，线程池中的工作线程执行任务并记录任务执行结果；

S7，服务重启或停止时，守护线程将线程池中未执行的任务重新添加到RedisList等待队列的尾部。

采用本发明的技术方案，通过Redis持久化存储任务，通过定时调度和线程池实现了对大批量任务的并发执行，控制了并发数、对系统解耦，降低了服务器的压力，保障了系统的稳定性；通过守护线程在服务停止前获取线程池中未执行的任务，并将未执行的任务追加到Redis的任务等待列表中，保证了系统重启时任务不丢失；任务中心和业务系统解耦，任务中心以组件的方式，提供大批量任务处理能力给各个业务系统引入使用，从而处理来自不同业务系统的任务，通用性和扩展性强；任务的执行记录存储于数据库，如果任务处理者类Processor处理异常，可将任务重新丢入任务队列进行重试，或单独记录起来用于分析，可追溯性强。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明一种大批量任务处理方法一个实施例所提供的业务流程示意图。

图2为本发明一种大批量任务处理方法一个实施例所提供的技术架构示意图。

图3为本发明一种大批量任务处理方法一个实施例所提供的时序示意图。

图4为本发明一种大批量任务处理方法一个实施例所提供的步骤流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合说明书附图对本发明实施例作进一步详细描述。应当理解，此处所描述的实施例仅用于说明和解释本发明，并不用于限定本发明。

本发明适用于大批量异步任务的处理，不支持任务的延时执行和有序执行。

如图1所示为本发明一实施例提供的一种大批量任务处理方法的业务流程示意图。在该实施例中，包含营销系统和采集系统两个业务系统，营销系统包含“发送短信通知”、“生成每人的问卷调查”两种任务，采集系统包含“上报设备数据”、“下发数据给下游系统”两种任务。图1中的营销系统、采集系统只是为了描述任务中心组件的使用者、使用方式，也可以替换成能够使用任务中心组件的任意业务系统，只要它们之间是同一套开发框架体系，能将任务中心组件引入。

如图2所示为本发明一实施例提供的一种大批量任务处理方法的技术架构示意图。本发明实施例采用Java开发语言实现，使用Spring Boot框架开发，任务中心以组件的形式向应用层的业务系统提供服务，业务系统以jar包的形式引入任务中心组件，任务中心组件提供的功能包括：接受任务、处理任务、任务记录、回调、定时调度。处理任务时使用的线程池采用Java线程池，定时调度任务采用Spring定时任务，数据库用于保存任务的执行记录，考虑到已执行的任务记录数据量较大，采用非关系型数据库Mongodb；任务等待队列采用Redis List，Redis的部署方式可单机、分布式、分片部署，本发明不详细概述Redis每种部署方式的的逻辑。其中，开发语言可以换成能支持线程池与服务关闭前能执行自定义逻辑的其他语言，开发框架可以根据开发语言的调整相应调整，定时任务也可以采用其它定时任务，比如xxl-job等，线程池与开发语言强相关，可以根据开发语言而调整，数据库可以根据引入的业务系统调整。

如图3所示为本发明一实施例提供的一种大批量任务处理方法的时序示意图。

如图4所示为本发明一实施例提供的一种大批量任务处理方法的步骤流程图。如图4所示，该方法包括以下步骤：

S1，各业务系统定义任务处理者类，并为每个任务处理者类绑定任务类型，具体步骤如下：

S11，定义各任务处理者类的公共接口，在接口中定义任务处理方法，各任务处理者类实现公共接口。

S12，实现自定义注解类，各任务处理者类通过自定义注解类绑定任务类型。

本发明实施例中，定义了ITaskProcessor接口作为各任务处理者类的公共接口，在其中定义了process()方法用于处理任务。自定义注解类为TaskSubscribe，伪代码如下所示，通过@Retention(RetentionPolicy.RUNTIME)修饰注解，以保证运行时有效，注册中心组件后续会通过注解反射获取到注解。

@Target({ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface TaskSubscribe {

String key() default "";

}

业务系统的各任务处理者类实现ITaskProcessor接口，并通过自定义注解类绑定任务类型，以营销系统中的“发送短信通知”任务处理者类为例，伪代码如下所示，类名为SmsTaskProcessor，通过implements实现了ITaskProcessor接口，通过注解//@TaskSubscribe(key="SMS")将任务类型“SMS”绑定到变量key。

//@TaskSubscribe(key="SMS")

public class SmsTaskProcessor implements ITaskProcessor{

@Override

public void process(Object o) {

// 这里是回调执行具体的方法

}

}

S2，任务中心组件初始化时，扫描任务处理者类，建立任务类型和任务处理者类的映射关系。

任务中心组件实现CommandLineRunner接口，通过各任务处理者类的公共接口识别每个任务处理者类，通过注解反射获取到任务类型注解，将任务类型与任务处理者类的映射关系转为map集合，保存到内存中。

在本发明实施例中，具体实现时，通过是否实现了ITaskProcessor接口来识别任务处理者类，通过注解反射获取到任务处理者类自定义注解TaskSubscribe中的key变量，比如对于营销系统中的“发送短信通知”任务处理者类，key的值为“SMS”，处理者类为SmsTaskProcessor，以“SMS”作为key，处理者类SmsTaskProcessor的路径为value，将“发送短信通知”任务的任务类型和处理者关系存入map集合中，map集合保存在内存中。

在步骤S2和步骤S3之间，还包括：

S2A，任务中心组件创建线程池，将参数RejectedExecutionHandler设置成AbortPolicy，在线程池饱和时抛出异常，并捕获该异常，在异常处理函数中将任务丢入Redis List等待队列尾部。

本发明实施例中，通过ThreadPoolExecutor的构造函数创建线程池，线程池的目的是在约束的规则内平缓的异步执行任务，所以建议参数不要设置太大，以下是几个核心参数配置建议：

corePoolSize：线程池中的常驻核心线程数，对于CPU密集型应用，建议将核心线程数设置为CPU核心数的1.5倍到2倍之间，对于IO密集型应用，建议将核心线程数设置为CPU核心数的2倍以上。

maximumPoolSize：线程池中能够容纳的最多线程数，建议最大线程数设置为CPU核心数的2倍到4倍之间。

workQueue：任务队列，建议使用有界队列，长度不超过1000。

S2B，任务中心组件创建定时任务，用于定时分发Redis List等待队列中的任务。

在本发明实施例中，定时任务采用Spring定时任务实现，通过类似@Scheduled(fixedRate = 10000)注解的方式来实现任务的定时执行，其中，fixedRate表示触发频率，其取值根据实际情况设置。定时任务也可以采用其它定时任务实现方式，比如xxl-job，或者线程定时sleep等。

S2C，任务中心组件创建守护线程，用于服务退出时的任务处理。

守护线程的实现是通过Runtime.getRuntime().addShutdownHook()绑定一个thread对象，服务退出的时候会自动执行Runtime.getRuntime().addShutdownHook()绑定的thread对象的方法。

S3，各业务系统向任务中心组件发起批量任务请求，任务信息包含任务类型、自定义扩展参数。

在本发明实施例中，营销系统、采集系统通过方法调用或者MQ等其他方式将任务信息发送给任务中心组件，任务信息包含：任务类型Key、自定义扩展参数，自定义扩展参数为执行任务所需要的业务参数，比如对于“发送短信通知”任务，自定义扩展参数包含短信内容、手机号码等。

S4，任务中心组件接收任务，将批量任务请求信息转JSON序列化后添加到RedisList等待队列头部。

任务中心组件将批量任务信息保存在Redis List等待队列中，采用Redis的目的是因为Redis支持大批量、高性能、可持久化存储。Redis的部署方式可单机、分布式、分片部署，本发明不详细概述Redis每种部署方式的的逻辑。

S5，定时任务在定时触发时，从Redis List等待队列的队尾循环取任务提交到线程池，当线程池饱和时退出本次循环。

本发明实施例中，线程池饱和的判断条件为：线程池任务数-已完成任务数≥线程池最大线程数+工作队列长度。线程池任务数可以通过ThreadPoolExecutor的getTaskCount()方法获得，已完成任务数可以通过ThreadPoolExecutor的getCompletedTaskCount()方法获得，线程池最大线程数是在创建线程池时指定的maximumPoolSize参数，工作队列长度在创建线程池时指定。

S6，线程池中的工作线程执行任务并记录任务执行结果，具体步骤包括：

S61，工作线程获取任务信息，通过任务类型和任务处理者类的映射关系，获取任务处理者实例。

线程池中的工作线程从工作队列中获取任务，将任务信息反序列化后，通过任务类型key，从内存中存储的任务类型和任务处理者映射关系map里查找到任务处理者类的路径，通过Spring Boot框架获取到任务处理者类的实例。

S62，工作线程通过任务处理者实例调用业务系统的任务处理方法。

工作线程通过从Spring Boot框架获取到的任务处理者类的实例，调用业务系统的任务处理方法进行任务处理，具体的任务实例函数在各业务系统中实现，和任务中心组件完全解耦。业务系统在任务处理完毕后，返回执行结果给线程池中发起调用的工作线程。

S63，工作线程将任务执行记录保存到数据库。

任务执行记录主要记录执行的任务类型key、自定义扩展参数、执行结果为成功还是异常等信息，类似日志方便追溯，考虑到已执行的任务记录数据量较大，本发明实施例中采用非关系型数据库Mongodb来保存任务执行记录。实际实施时，可以根据需要选择数据库。

如果任务处理者类Processor返回的处理结果为异常，可将任务重新丢入任务队列进行重试，或单独记录起来用于分析。

S7，服务重启或停止时，守护线程将线程池中未执行的任务重新添加到RedisList等待队列的尾部。

业务系统向任务中心组件提交的批量任务被任务中心组件存储在Redis List等待队列中，Redis作为非关系型数据库，自带持久化支持，数据丢失风险很低，但应用服务器重启或停止时，线程池中未执行的任务会丢失。

本发明实施例利用线程钩子的特性，通过Runtime.getRuntime().addShutdownHook()绑定守护线程，在服务停止或重启之前，守护线程调用ThreadPoolExecutor的shutdownNow()方法获取工作队列中未执行的任务的参数，将线程池未执行的任务重新添加到Redis等待队列的尾部。

因为定时任务每次向线程池提交任务的时候，是从Redis List等待队列的队尾取任务的，在守护线程中将未执行的任务添加到Redis List等待队列的尾部，服务下次启动后，定时任务优先将这批任务提交到线程池执行。

采用本发明的技术方案，通过Redis持久化存储任务，通过定时调度和线程池实现了对大批量任务的并发执行，控制了并发数、对系统解耦，降低了服务器的压力，保障了系统的稳定性；通过守护线程在服务停止前获取线程池中未执行的任务，并将未执行的任务追加到Redis的任务等待列表中，保证了系统重启时任务不丢失；任务中心和业务系统解耦，任务中心以组件的方式，提供大批量任务处理能力给各个业务系统引入使用，从而处理来自不同业务系统的任务，通用性和扩展性强；任务的执行记录存储于数据库，如果任务处理者类Processor处理异常，可将任务重新丢入任务队列进行重试，或单独记录起来用于分析，可追溯性强。

以上仅为本发明的具体实施方式，不能以此来限定本发明的范围，本技术领域内的一般技术人员根据本创作所作的均等变化，以及本领域内技术人员熟知的改变，都应仍属本发明涵盖的范围。

Claims (7)

1.一种大批量任务处理方法，其特征在于，包括以下步骤：

S1，各业务系统定义任务处理者类，并为每个任务处理者类绑定任务类型；

S2，任务中心组件初始化时，扫描任务处理者类，建立任务类型和任务处理者类的映射关系；

S3，各业务系统向任务中心组件发起批量任务请求，任务信息包含任务类型、自定义扩展参数；

S4，任务中心组件接收任务，将批量任务请求信息转JSON序列化后添加到Redis List等待队列头部；

S5，定时任务在定时触发时，从Redis List等待队列的队尾循环取任务提交到线程池，当线程池饱和时退出本次循环；

S6，线程池中的工作线程执行任务并记录任务执行结果；

S7，服务重启或停止时，守护线程将线程池中未执行的任务重新添加到Redis List等待队列的尾部；

所述任务中心以组件的形式向应用层的业务系统提供服务，业务系统以jar包的形式引入任务中心组件；

所述步骤S2与步骤S3之间还包括：

S2A，任务中心组件创建线程池，将参数RejectedExecutionHandler设置成AbortPolicy，在线程池饱和时抛出异常，并捕获该异常，在异常处理函数中将任务丢入Redis List等待队列尾部；

S2B，任务中心组件创建定时任务，用于定时分发Redis List等待队列中的任务；

S2C，任务中心组件创建守护线程，用于服务退出时的任务处理。

2.根据权利要求1所述的大批量任务处理方法，其特征在于，所述步骤S1包括以下步骤：

S11，定义各任务处理者类的公共接口，在接口中定义任务处理方法，各任务处理者类实现公共接口；

S12，实现自定义注解类，各任务处理者类通过自定义注解类绑定任务类型。

3.根据权利要求2所述的大批量任务处理方法，其特征在于，所述步骤S2具体实现方式为：任务中心组件实现CommandLineRunner接口，通过各任务处理者类的公共接口识别每个任务处理者类，通过注解反射获取到任务类型注解，将任务类型与任务处理者类的映射关系转为map集合，保存到内存中。

4.根据权利要求1所述的大批量任务处理方法，其特征在于，所述步骤S6包括以下步骤：

S61，工作线程获取任务信息，通过任务类型和任务处理者类的映射关系，获取任务处理者实例；

S62，工作线程通过任务处理者实例调用业务系统的任务处理方法；

S63，工作线程将任务执行记录保存到数据库。

5.根据权利要求1所述的大批量任务处理方法，其特征在于，步骤S2C中，守护线程的实现是通过Runtime.getRuntime().addShutdownHook()绑定一个thread对象。

6.根据权利要求1所述的大批量任务处理方法，其特征在于，所述步骤S7中，守护线程调用ThreadPoolExecutor的shutdownNow()方法获取工作队列中未执行的任务的参数。

7.根据权利要求1所述的大批量任务处理方法，其特征在于，所述步骤S6中，任务执行记录包括执行的任务类型key、自定义扩展参数、执行结果。