1.四种分布式任务调度框架对比
| 对比内容 | quartz框架 | XXL-Job | Elastic-Job |
|---|---|---|---|
| 依赖 | mysql | mysql,jdk1.7+,maven3.0+ | jdk1.7+,zookeeper3.4.6+,maven3.0.4+,mesos |
| 任务分片 | 不支持 | 支持 | 支持 |
| 管理界面 | 无 | 支持 | 支持 |
| 高级功能 | 无 | 弹性扩容,分片广播,故障转移,Rolling实时日志,GLUE(支持在线编辑代码,免发布),任务进度监控,任务依赖,数据加密,邮件报警,运行报表,国际化 | 弹性扩容,多种作业模式,失效转移,运行状态收集,多线程处理数据,幂等性,容错处理,spring命名空间支持 |
| 缺点 | 没有管理界面,以及不支持任务分片等。不适用于分布式场景 | 调度中心通过获取DB锁来保证集群中执行任务的唯一性,如果短任务很多,随着调度中心集群数量增加,那么数据库的锁竞争会比较厉害,性能不好。 | 需要引入zookeeper,mesos,增加系统复杂度,学习成本较高 |
| 任务不能重复执行 | 数据库锁 | 使用Quartz基于数据库的分布式功能 | 将任务拆分为n个任务项后,各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群,或现有服务器下线,elastic-job将在保留本次任务执行不变的情况下,下次任务开始前触发任重分片。 |
| 并行调度 | 调度系统多线程(默认10个线程)触发调度运行,确保调度精确执行,不被堵塞。 | 采用任务分片方式实现。将一个任务拆分成n个独立的任务项,由分布式的服务器并行执行各自分配到的分片项。 | |
| 失败处理策略 | 调度失败时的处理策略,策略包括:失败告警(默认)、失败重试(界面可配置) | 弹性扩容缩容在下次作业运行前重分片,但本次作业执行的过程中,下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。 |
总结
quartz
- 调用API的的方式操作任务,不人性化;
- 需要持久化业务QuartzJobBean到底层数据表中,系统侵入性相当严重。
- 调度逻辑和QuartzJobBean耦合在同一个项目中,这将导致一个问题,在调度任务数量逐渐增多,同时调度任务逻辑逐渐加重的情况加,此时调度系统的性能将大大受限于业务;
Quartz关注点在于定时任务而非数据,并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用,但缺少分布式并行调度的功能。
xxl-job
侧重的业务实现的简单和管理的方便,学习成本简单,失败策略和路由策略丰富。推荐使用在“用户基数相对少,服务器数量在一定范围内”的情景下使用。
elastic-job
关注的是数据,增加了弹性扩容和数据分片的思路,以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些,推荐在“数据量庞大,且部署服务器数量较多”时使用。
