分布式定时任务框架选型，写得太好了！

大佬教程收集整理的这篇文章主要介绍了分布式定时任务框架选型，写得太好了！，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

作者：joni@efbiz.org

来源：http://www.expectfly.com/2017/08/15/分布式定时任务方案技术选型/

@H_618_4@为什么我们需要定时任务

我们先思考下面几个业务场景的解决方案:

• 支付系统每天凌晨1点跑批，进行一天清算，每月1号进行上个月清算
• 电商整点抢购，商品价格8点整开始优惠
• 12306购票系统，超过30分钟没有成功支付订单的，进行回收处理
• 商品成功发货后，需要向客户发送短信提醒

很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。

如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。

但在某些场景下不能互换：

有哪些定时任务的框架

单机

• timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程
• scheduledExecutorservice：相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间
• spring定时框架：配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器

分布

• Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
• TBschedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBschedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
• elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
• Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
• xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

分布式任务调度系统对比

项目背景及社区力量

X-Job　：　大众点评公司下员工许雪里、贡献者 3人;　github有2470star、1015fork　|　QQ讨论群6个　|　有登记在使用的超过40家公司　|　文档齐全
E-Job　：　当当网开源，贡献者17人;　github有2524star、1015fork　|　QQ讨论群１个、源码讨论群１个　|　有登记在使用的超过50家公司　|　文档齐全　｜　有明确的发展计划

支持集群部署

X-Job　：　集群部署唯一要求为：保证每个集群节点配置（db和登陆账号等）保持一致。调度中心通过db配置区分不同集群。

E-Job　：　重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心

多节点部署时任务不能重复执行

X-Job　：　使用Quartz基于数据库的分布式功能

E-Job　 ：　将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。

日志可追溯

X-Job　：　支持，有日志查询界面

E-Job　：　可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。

监控告警

X-Job　：　调度失败时，将会触发失败报警，如发送报警邮件。

E-Job　：　通过事件订阅方式可自行实现

弹性扩容缩容

X-Job　：　使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力

E-Job　：　通过zk实现各服务的注册、控制及协调

支持并行调度

X-Job　：　调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞。

E-Job　：　采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。

高可用策略

X-Job　：　“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；

E-Job　：　调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群，集群中只有一个调度器实例提供服务，其他实例处于”待命”状态。当该实例失败时，集群会选举剩余实例中的一个来继续提供服务。

失败处理策略

X-Job　：　调度失败时的处理策略，策略包括：失败告警（默认）、失败重试；

E-Job　：　弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。

动态分片策略

X-Job　：　分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。

E-Job　：　支持多种分片策略，可自定义分片策略

和quartz框架对比

• 调用API的的方式操作任务，不人性化；
• 需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
• 调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务；
• Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。

综合对比

总结和结论

共同点：

E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。

不同点：

X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。

E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用

附定时任务的其他方案

发货后超过10天未收货时系统自动确认收货的多种实现方式：

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2021最新版)

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式发布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！

大佬总结

以上是大佬教程为你收集整理的分布式定时任务框架选型，写得太好了！全部内容，希望文章能够帮你解决分布式定时任务框架选型，写得太好了！所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。