| xxl-job ★★★★★ |
elastic-job ★★★★ |
TBSchedule ★★★★ |
Easy Task ★★★ |
|
|---|---|---|---|---|
| 开源时间 | 2015年11月22日 | 2016年2月 | 2012年 | 2018年1月 |
| 厂商 | 许雪里，贡献者16人，大众点评内部： Ferrari-法拉利 | 当当网开源，贡献者17人 | 阿里开源，github无正式下载，无贡献者 | 淘宝彩票调度平台，jar包公司时铁甲网 |
| 社区力量 | ★6759 fork 2893 公司:155+ | ★4540 fork 2152 公司:50 | 无 | ★17 fork 18 |
| 更新时间 | 20天前 | 1年前 | 无 | 3个月前 |
| 周期执行 | 支持 | 支持 | 支持 | 支持 |
| 定时执行 | 最终一致 | 最终一致 | 支持 | |
| Dataflow任务 | 支持 | |||
| 事件触发 | 支持 | |||
| 脚本任务 | Shell、Python、NodeJS、PHP | shell，python，perl | ||
| 弹性扩容缩容 | 基于DB的 | 基于ZK的 | ||
| 故障转移 | 支持，Failover | 支持 | 支持 | 支持 |
| 阻塞处理 | 单机串行(默认) | zk的session timeout | ||
| 动态分片 | 支持 | 支持 | ||
| 广播任务 | 支持 | 支持 | ||
| 并行调度 | 多线程 | 将任务分片成小任务 | timer | |
| 任务依赖 | 支持 | 支持 | ||
| 任务进度监控 | 支持 | ?? | ||
| 任务失败重试 | 支持自定义次数 | ?? | ||
| 日志 | 支持，有界面 | 有API,需调用 | 很简单 | |
| 报警 | 邮件,API支持短信 | 多样，可定制 | ||
| 报表 | 支持 | ?? | ||
| openAPI | ？？ | 支持 | ||
| Spring | 支持，springboot | 支持，springboot | ||
| 调度中心支持集群部署 | 支持 | 支持 | ||
| 文档完善 | 支持 | 支持 | 不支持 | |
| 难易程度 | 简单 | 较复杂 | ||
| 高级功能 | 弹性扩容，分片广播，故障转移，Rolling实时日志，GLUE（支持在线编辑代码，免发布）,任务进度监控，任务依赖，数据加密，邮件报警，运行报表，国际化 | 弹性扩容，多种作业模式，失效转移，运行状态收集，多线程处理数据，幂等性，容错处理，spring命名空间支持 | ||
| 缺点 | 调度中心通过获取 DB锁来保证集群中执行任务的唯一性， 如果短任务很多，随着调度中心集群数量增加，那么数据库的锁竞争会比较厉害，性能不好。 | 需要引入zookeeper , mesos, 增加系统复杂度, 学习成本较高 | ||
| 场景推荐 | 用户基数相对少，服务器数量在一定范围内 | 数据量庞大，且部署服务器数量较多 | ||
| 使用企业 | 大众点评，运满满，优信二手车，拍拍贷 | 36氪，当当网，国美，金柚网，联想，唯品会，亚信，平安，猪八戒 | ||
| 依赖 | mysql ,jdk1.7+ , maven3.0+ | jdk1.7+, zookeeper 3.4.6+ ,maven3.0.4+ ,mesos |
指标解释：
弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
阻塞处理策略：调度过于密集执行器来不及处理时的处理策略
任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；
动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
事件触发：支持基于事件的触发任务方式
广播执行：
并行计算：
job就是将一个耗时很长的大任务拆分成多个小的子任务然后分发到多台机器去并行执行。
任务依赖：
这种特性往往用于有业务数据依赖的多个任务之间按照严格先后顺序执行的场景。阿里内部有很多这种场景，两个或者多个任务之间按照某种业务逻辑顺序去执行，比如两个任务A，B其中A执行结束之后B才能开始执行
共同点
共同点： E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。
不同点
X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用
E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用
Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。
Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理、应用分发以及进程隔离等服务
亮点：
基于quartz 定时任务框架为基础的，因此具备quartz的大部分功能
使用zookeeper做协调，调度中心，更加轻量级
支持任务的分片
支持弹性扩容 ， 可以水平扩展 ， 当任务再次运行时，会检查当前的服务器数量，重新分片，分片结束之后才会继续执行任务
失效转移，容错处理，当一台调度服务器宕机或者跟zookeeper断开连接之后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务
架构图：
XXL
E-JOB
E-JOB-Lite
E-JOB-CLOUD
THE END