前言

目前市面上任务调度的框架有很多，本文主要谈一下分布式任务调度框架xxl-job和PowerJob的相同点和不同点。

贴一下两款框架的相关链接

xxl-job

PowerJob

整体对比(参考了PowerJob官网)

产品名称	xxl-job	PowerJob
定时类型	CRON、固定速度	CRON、固定速度、固定延迟、OpenAPI
任务类型	内置Java、GLUE(Java、Shell、Python等脚本)	内置Java、外置Java(容器)、Shell、Python脚本
分布式任务	静态分片	MapReduce动态分片
在线任务治理	支持	支持
日志白屏化	支持	支持
调度方式及性能	基于数据库锁	无锁化设计
报警监控	邮件	邮件、WebHook、钉钉、提供了接口允许开发者扩展
系统依赖	MySQL	任意Spring Data Jpa支持的关系型数据库(MySQL、Oracle等)
DAG 工作流	不支持	支持

相同点

无论是xxl-job还是PowerJob都是调度中心模块和任务执行模块完全解耦的模式，而且调度中心都支持docker镜像部署。两者都支持集群化，都提供web页面可以进行对任务进行CRUD，监控任务状态，查看任务日志等。

不同点

数据库支持

xxl-job目前支持MySQL，执行/xxl-job/doc/db/tables_xxl_job.sql路径下的脚本，而PowerJob的持久层是基于Spring Data Jpa实现的，只需要创建数据库即可

执行SQL：CREATE DATABASE IF NOT EXISTS `powerjob-product` DEFAULT CHARSET utf8mb4

Web页面

两者页面能实现的功能大体相同，只是在用户管理方面有较大的区别。PowerJob的执行器和用户是分开注册的，目前没有权限控制，而且执行器需要需要先手动注册才能接入调度中心；而xxl-job只需要注册用户，而且带有权限控制，任务的执行器通过access_token自动注册到调度中心

任务类型

xxl-job

Bean模式支持类和方法两种形式

Bean模式(类形式)
1、开发一个继承自"com.xxl.job.core.handler.IJobHandler"的JobHandler类，实现其中任务方法。
2、手动通过如下方式注入到执行器容器。
```
XxlJobExecutor.registJobHandler("demoJobHandler", new DemoJobHandler());
```

Bean模式(方法形式)
1、任务开发：在Spring Bean实例中，开发Job方法；
2、注解配置：为Job方法添加注解 "@XxlJob(value="自定义jobhandler名称", init = "JobHandler初始化方法", destroy = "JobHandler销毁方法")"，注解value值对应的是调度中心新建任务的JobHandler属性的值。
3、执行日志：需要通过 "XxlJobHelper.log" 打印执行日志；
4、任务结果：默认任务结果为 "成功" 状态，不需要主动设置；如有诉求，比如设置任务结果为失败，可以通过 "XxlJobHelper.handleFail/handleSuccess" 自主设置任务结果；
```
@XxlJob("demoJobHandler")
public void demoJobHandler() throws Exception {
    XxlJobHelper.log("XXL-JOB, Hello World.");
}
```

GLUE模式是通过Web IDE在线编辑更新，实时编译和生效，支持Java、Shell、Python等脚本

PowerJob

外置Java容器是JVM级的容器，以Maven工程项目的维度去组织Java文件。具体先通过页面的模板生成，生成一个容器的工程，然后每次更新重新部署，目前只支持Git代码库和FatJar的形式来运行容器

内置Java、Shell、Python等都是基于处理器Processor来进行开发

● Java 处理器可根据对象创建者划分为 SpringBean 处理器和普通 Java 对象处理器，
前者由 Spring IOC 容器完成处理器的创建和初始化，后者则由 PowerJob 维护其生命
周期。

● Java处理器可根据功能划分为单机处理器、广播处理器、Map 处理器和 MapReduce 处理器。
  ○ 单机处理器（BasicProcessor）对应了单机任务，即某个任务的某次运行只会有某一台机器的某一个线程参与运算。
  ○ 广播处理器（BroadcastProcessor）对应了广播任务，即某个任务的某次运行会调动集群内所有机器参与运算。
  ○ Map处理器（MapProcessor）对应了Map任务，即某个任务在运行过程中，允许产生子任务并分发到其他机器进行运算。
  ○ MapReduce 处理器（MapReduceProcessor）对应了 MapReduce 任务，在 Map 任务的基础上，增加了所有任务结束后的汇总统计。

● 对于其他的Shell、Python等只需要引入依赖，然后配置任务的时候填写官方处理器的全限定类名
<dependency>
    <groupId>tech.powerjob</groupId>
		<artifactId>powerjob-official-processors</artifactId>
		<version>${latest.version}</version>
</dependency>

分布式任务

xxl-job中提供了分片广播的路由策略，这个路由策略的实现原理，其实是读取到当前注册的执行器下的所有机器，携带者机器index，总机器数total，将请求发送给所有的机器，具体的实现根据客户端接收到的index和tital来进行哈希分配

PowerJob使用了MapReduce的思想， 由调度端调度端发一个请求给某一个客户端，请求参数携带了当前APPNAME下的所有客户端地址客户端参数等，接收到请求的客户端承担map的职责分发任务，监控任务执行状态。各个客户端执行完毕之后，会给分发请求的客户端响应，并由此客户端承担Reduce的职责来汇总执行结果

调度性能

xxl-job使用了数据库锁，来保证在多台调度段同时工作时，仅有一台机器提供调度工作

PowerJob引入了执行器分组的概念。同一个执行器APPNAME仅有一台机器来调度，这样实现了调度的横向扩展，也避免了同一个任务被重复执行

工作流

目前xxl-job还不支持工作流，只有父子任务触发，即每个任务都拥有一个唯一的任务ID，当本任务执行结束并且执行成功时，将会触发子任务ID所对应的任务的一次主动调度

报警模块

PowerJob目前比xxl-job支持的形式更多，除了邮件外还有Web Hook、钉钉等，而且还支持开发者自己扩展，反观xxl-job只有邮件

扩展API

PowerJob是直接提供了OpenAPI，方便Java应用扩展，只需要添加依赖，通过PowerJobClient这个类去扩展

<dependency>
	<groupId>tech.powerjob</groupId>
	<artifactId>powerjob-client</artifactId>
	<version>${latest.powerjob.version}</version>
</dependency>

xxl-job针对Java应用可以直接通过官方提供的调度中心与执行器，针对非Java应用则是给调度中心和执行器提供语言无关的RESTful API。

总结

总的来说PowerJob在现阶段功能确实是比xxl-job要更为完善，但不可否认的是两者都是很优秀的任务调度框架，而且也都在完善各自的不足之处。xxl-job也在规划DAG工作流、多数据库支持和告警增强；PowerJob也在完善应用注册和权限管理方面的需求。

参考文章

https://blog.csdn.net/weixin_44692700/article/details/119570317