背景
PowerJob 可以被认为是第三代任务调度框架,在任务调度的基础上,还额外提供了分布式计算和工作流功能,其主要特性如下:
- 使用简单:提供 Web 界面,允许开发者可视化地完成调度任务的管理(增、删、改、查)、任务运行状态监控和运行日志查看等功能。
- 定时策略完善:支持 CRON 表达式、固定频率、固定延迟和API四种定时调度策略。
- 执行模式丰富:支持单机、广播、Map、MapReduce 四种执行模式,其中 Map/MapReduce 处理器能使开发者寥寥数行代码便获得集群分布式计算的能力。
- 工作流(workflow)支持:支持在线配置任务依赖关系,可视化得对任务进行编排,同时还支持上下游任务间的数据传递
- 执行器支持广泛:支持 Spring Bean、内置/外置 Java 类、Shell、Python 等处理器,应用范围广。
- 运维便捷:支持在线日志功能,执行器产生的日志可以在前端控制台页面实时显示,降低 debug 成本,极大地提高开发效率。
- 依赖精简:最小仅依赖关系型数据库(MySQL/PostgreSQL/Oracle/MS SQLServer 等),同时支持所有 Spring Data JPA 所支持的关系型数据库。
- 高可用&高性能:调度服务器经过精心设计,一改其他调度框架基于数据库锁的策略,实现了无锁化调度。部署多个调度服务器可以同时实现高可用和性能的提升(支持无限的水平扩展)。
- 故障转移与恢复:任务执行失败后,可根据配置的重试策略完成重试,只要执行器集群有足够的计算节点,任务就能顺利完成。
PowerJob 适用场景
综上所述,PowerJob 是全新一代分布式调度与计算框架,能让您轻松完成任务的调度与繁杂任务的分布式计算。适用于各个有任务调度需求的企业,统一部署 Server 做为整个公司的公共调度平台,成为分布式调度的中间件。
- 有定时执行需求的业务场景:如每天凌晨全量同步数据、生成业务报表等。
- 有需要全部机器一同执行的业务场景:如使用广播执行模式清理集群日志。
- 有需要分布式处理的业务场景:比如需要更新一大批数据,单机执行耗时非常长,可以使用 Map/MapReduce 处理器完成任务的分发,调动整个集群加速计算。
PowerJob与同类型产品对比
QuartZ | xxl-job | ElasticJob | SchedulerX 2.0 | PowerJob | |
---|---|---|---|---|---|
定时类型 | CRON | CRON | CRON、OpenAPI | CRON、固定频率、固定延迟、OpenAPI | CRON**(15秒以上)、固定频率、固定延迟(控制台设置的2倍时间)、OpenAPI** |
任务类型 | 内置Java | 内置Java、GLUE Java、Shell、Python等脚本 | 内置Java、Shell、Python等脚本 | 内置Java、外置Java(FatJar)、Shell、Python等脚本 | 内置Java、外置Java(容器)、Shell、Python等脚本 |
分布式任务 | 无 | 静态分片 | 静态分片 | MapReduce 动态分片 | MapReduce 动态分片 |
在线任务治理 | 不支持 | 支持 | 支持 | 支持 | 支持 |
日志白屏化 | 不支持 | 支持 | 添加 ElasticJob-UI**组件后支持** | 不支持 | 支持 |
调度方式及性能 | 基于数据库锁,有性能瓶颈 | 基于数据库锁,有性能瓶颈 | 基于Zookeeper分布式锁,调度端可以动态水平扩容,高可用高性能。 | 不详(云服务的功能决定,那边控制限流后性能自然会降低) | 无锁化设计(调度端调度任务这一操作无锁),性能强劲无上限 |
报警监控 | 无 | 邮件 | 邮件、企业微信、钉钉 | 短信 | 邮件,提供接口允许开发者扩展 |
系统依赖 | 关系型数据库(MySQL、Oracle…) | MySQL | Zookeeper | 人民币 | 任意 Spring Data Jpa支持的关系型数据库(MySQL、Oracle…) |
DAG 工作流 | 不支持 | 不支持 | 有简单流处理,DAG官网显示todo(在做了但不知道啥时候做完) | 支持 | 支持 |
技术选型总结
PowerJob:
优点:
相较于xxl-job和ElasticJob,power job调度操作无锁,更具备高并发高性能优势。
相较于ElasticJob更轻量级,没有其他必须的中间件支持,方便管理。
相较于xxl-job必须使用mysql,powerJob支持的数据库连接总类丰富,对数据库的操作大多使用spring data jpa实现,理论上只要jpa支持的数据库都可以使用。
系统设计理论基于阿里的自研中间件Schedulerx2.0,具备Map/Reduce大数据分布式计算、DAG工作流调度、脚本调度、API、容器(JVM 级容器jar包,非操作系统级容器Docker)执行等高级功能。
PowerJob的调度中心具备高性能特性,调度中心只关注调度任务及其结果,定时任务的执行压力都被分摊到各个worker执行端(使用调度服务的应用端),且如果定时执行时间达到毫秒级别(非cron表达式的前提)任务的下次执行时间等计算也都交给执行端,调度中心CPU计算压力较小性能高。
缺点:
社区相对没有xxl-job和ElasticJob活跃,github上关注人数没有另外2个多,开发测试人员较少,测试覆盖范围可能没有其他2个广(MySqlSeriesDfsService这个容器高级特性的实现类注解写明官方只基于mysql进行了测试)。
对于没有分布式计算、集群控制等高级特性使用需求的话会导致部分线程空转影响性能。
调度中心不支持动态扩容,需停机重新发版。
使用jpa考虑了使用各种数据库的兼容性,但很多地方如果改成对应库的sql查询能提高很大的性能(将foreach循环中的调度jpa查询库改成单个sql查询结果)。
xxl-job:
优点:
非常轻量级,相较于powerJob和ElasticJob轻量、简单、易上手。
社区活跃,github上关注最多,测试覆盖面全,问题方便排查。
缺点:
基于数据库锁实现分布式锁避免重复调度(select for update), 避免了重复调度问题但加锁减少了并发能力。
不支持powerJob提供的高级特性,数据库支持种类单一强依赖mysql。
调度中心不支持动态扩容。
ElasticJob:
优点:
服务发现与注册端zookeeper支持动态扩容。
Apache ShardingSphere 的子项目,开发维护人员较多,使用广泛。
缺点:
相较于xxl-job和powerJob添加了zookeeper的依赖。
不支持powerJob提供的map/Reduce分布式计算、DAG工作流等高级特性。
Elastic-Job的弹性分布式功能强依赖zookeeper,zookeeper容易成为性能瓶颈。
任务划分的分片数可能小于执行任务的实例数,导致一些机器空转。
使用须知
部署顺序
Power-job作者基于快速失败考虑,各个worker调度端(应用端)系统必须成功连接到server端(power-job调度中心应用)才能启动,所以在补丁维护,系统重启等情况下需要先启动应用powerjob-server
端口开放控制
最省事的方法:所有端口(7700 + 10086 + 10010)全打开。如果你想精细化控制端口,那么请遵循以下原则自行设置:
- 对于任何用户,7700 为调度服务器(powerjob-server)的 Web 服务端口,必须打开
- oms.协议.port 的端口按需打开,考虑 server-server 和 server-worker 通讯的场景:
l 比如 server-server 默认通过 HTTP 协议交互(参数 oms.transporter.main.protocol控制),那必须打开 HTTP 10010 端口
l 同时 server-worker 部分通过 HTTP,部分通过 AKKA,则仍需要打开 AKKA 的 10086 端口
官方产品手册未提及的可能导致bug的特性
1.低于15秒的cron表达式执行间隔为15秒
2.固定延迟执行时间与预期不符,不建议使用
示例:
控制台配置固定延迟为8秒,延迟时间并发期望的8秒,且会立即执行一次
3. 固定频率源码限制死了不能低于50毫秒间隔频率但是返回异常要求频率应高于1000毫秒
代码配置(开发)
yaml & properties 配置注意(开发)
使用部署调度端之前请删除&添加以下配置:
l 添加配置(非必须):
下面配置用以提升批量插入情况下性能
1 | spring.jpa.properties.hibernate.jdbc.batch_size=1000 |
l 删除配置(必须)
下面配置涉及钉钉登陆和报警请删除
1 | ####### DingTalk properties(Non-core configuration properties) ####### |
低版本spring boot 配置类
springboot低于2.7.4的版本,的项目无法注册到server调度端,启动报错,需手写配置类。
相关issue地址: https://github.com/PowerJob/PowerJob/issues/622
参考配置类
1 | import org.springframework.context.annotation.Bean; |
版本选择
本调研报告主要基于5.1.0版本编写,该版本于2024/08/11合并发布到master分支,不建议使用5.x之前版本,4.x版本密码明文存储没有全局管理账号概念,每一个应用集群对应一个账号不便管理。更早版本缺少维护。
Maven版本仓库地址:
...
...
This is copyright.