一、背景
本文档为解决分布式场景下定时任务重复执行的问题提供选型参考。其中大部分描述来自互联网资料整合,相关链接在文档底部。
主要需求如下:
1.避免重复执行
2.动态CRUD,如动态启停、业务中允许更新执行时间。
3.失效转移、负载均衡等分布式作业管理
4.定时任务管理,如查看当前任务列表、手动启停等。
5.日志回溯、异常报警等。
二、概览
经过检索找到如下几种用户群较多的候选框架。
quartz是最经典最著名的任务调度框架,其他候选至少初期都是基于它开发,进而改进了quartz的问题。
Quartz关注点在于定时任务而非数据,并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用,但缺少分布式并行调度的功能。同时它通过独占锁来保证只有一个节点执行,没有负载均衡,并且需要持久化任务信息到业务数据表,有10张以上,对业务有侵入性。最后,调度和执行并存于同一个项目,相互影响性能。
结论:由于以上原因,实际场景不会直接选择quartz作为调度框架。
三、详细对比
对比内容 |
xxl-job |
elastic-job |
项目背景 |
大众点评开源项目 |
当当网开源项目 |
社区力量 |
18人/fork3289/公司180 |
17人/fork2252/公司50 |
文档 |
非常详细 |
详细 |
可视化 |
支持通过web页面对任务进行CRUD操作,支持报表及日志查看 |
支持通过web页面对任务进行CRUD操作,用户权限管理等 |
规则触发 |
时间触发和事件触发 |
时间触发 |
调度器集群部署 |
支持 |
支持 |
作业集群部署 |
支持 |
支持 |
日志追溯 |
支持,日志查询页面 |
通过事件订阅的方式处理调度过程的重要事件 |
报警 |
默认提供邮件失败告警,可扩展短信、钉钉等方式 |
实现报警接口 |
弹性扩容 |
使用quartz使用数据库的分布式供能,一旦有新执行器机器上线或下线,下次调度时将重新分配任务 |
通过zk实现各服务的注册、控制及协调,运行中的作业服务器崩溃,或新增n台作业服务器,将在下次作业前重新分片,不影响当前作业执行 |
阻塞策略 |
单机串行,丢弃后续调度,覆盖之前的调度 |
Zk的session timeout超时。临时节点会被清除,作业才会重新分片 |
失败处理策略 |
失败告警、失败重试、故障转移 |
失败转移、被错过的任务重新触发 |
Spring整合 |
Springboot启动,和spring整合简单 |
|
支持并行调度 |
调度系统多线程触发调度运行,确保调度精确执行,不被阻塞 |
将一个任务分为多个小任务在多台服务器上执行 |
高可用 |
通过DB锁来保证集群分布式调度的一致性,一次任务调度只会触发一次,如果执行器集群中某一台机器故障,将会自动failover切换到正常机器 |
通过zk来保证集群分布式调度,调度器的高可用是通过运行几个指向同一个zk集群的Elastic-job-cloud-scheduler实例来实现的,zk用于当前主实例失败的情况下leader选举 |
自定义任务参数 |
支持在线配置调度任务入参,即时生效 |
在修改任务时,可以自定义参数 |
任务进度监控 |
支持实时监控任务进度 |
监控作业运行时状态,统计最近一段时间处理的数据成功和失败数量,记录作业上次运行begin Time,endTime,nextTime |
灰度发布 |
支持灰度发布 |
|
容器部署 |
支持docker部署 |
|
支持语言 |
任务开发语言不受限制 |
任务开发语言不受限制 |
生产支持 |
节点350+ 任务调度4000w/天 |
|
分片广播任务 |
执行器集群部署时,任务路由策略选择“分片广播”情况下,一次任务调度将会触发集群中所有执行器执行一次任务,可根据分片参数开发分片任务 |
通过zk实现分片,主节点进行分片,以下三种情况会触发执行分片: 1.新的job加入集群 2.现有job下线,如果下线的是leader节点,那么先选举然后触发分片算法执行 3.主节点选举 |
动态分片 |
分片广播任务以执行器为维度进行分片,支持动态扩容执行器集群从而动态增加分片数量,协同进行业务处理。在进行大数量业务操作时可显著提升任务处理速度和能力 |
|
依赖 |
ZooKeeper,mesos(仅elasticjob-cloud) |
|
易用性 |
一般 |
较复杂 |
使用场景 |
数据量较小、服务器较少的快速开发场景,主打轻量级。 |
注重数据设计,适合数据量大、服务器多的场景。 |
特有属性 |
资源分配,应用分发,进程级调度,瞬时任务,进程隔离。(Mesos自研框架实现) |
|
共有属性 |
1.作业治理(失效转移,错过重新执行,自诊断修复,负载均衡) 2.弹性扩容,数据分片。 3.可视化管理,任务统计,日志,报警。 4.动态CRUD 5.与Spring、Dubbo配合良好。 |
1.作业治理(失效转移,错过重新执行,自诊断修复,负载均衡) 2.弹性扩容,数据分片。 3.可视化管理,任务统计,日志,报警。 4.动态CRUD 5.与Spring、Dubbo配合良好。 |
四、结论
XXL-Job 侧重于业务实现的简单和管理的方便,学习成本低,失败策略和路由策略丰富。推荐使用在“用户基数相对少,服务器数量在一定范围内”的情景下使用
Elastic-Job 关注的是数据,增加了弹性扩容和数据分片的思路,以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些,推荐在“数据量庞大,且部署服务器数量较多”时使用
对于并发场景不是特别高的系统来说,xxl-job配置部署简单易用,不需要引入多余的组件,同时提供了可视化的控制台,使用起来非常友好,是一个比较好的选择。
更倾向于选择XXL-JOB:
1.轻量级,支持通过Web页面对任务进行动态CRUD操作,操作简单
2.只依赖数据库作为集群注册中心,接入开发简单,不需要ZK
3.高可用、解耦、高性能、监控报警、分片、重试、故障转移
4.团队持续开发,社区活跃
5.支持后台直接查看每个任务执行实时日志,ELASTIC-JOB中应该是没有这个功能
五、参考资料
Quartz:
https://www.w3cschool.cn/quartz_doc/
ElasticJob官方:
https://shardingsphere.apache.org/elasticjob/current/cn/overview/
https://github.com/apache/shardingsphere-elasticjob
XXL-Job官方:
https://www.xuxueli.com/xxl-job/
https://github.com/xuxueli/xxl-job
标签:job,作业,调度,选型,集群,任务,分片,任务调度,分布式 From: https://www.cnblogs.com/makeBuger/p/17087194.html