分布式定时任务调度系统

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

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

>类似的业务场景非常多，我们怎么解决？

二：为什么我们需要定时任务

很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。

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

a)时间驱动/事件驱动：内部系统一般可以通过时间来驱动，但涉及到外部系统，则只能使用时间驱动。如怕取外部网站价格，每小时爬一次

b)批量处理/逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理。如移动每个月结算我们的话费

c)实时性/非实时性：消息中间件能够做到实时处理数据，但是有些情况下并不需要实时，比如：vip升级

d)系统内部/系统解耦：定时任务调度一般是在系统内部，而消息中间件可用于两个系统间

三:任务框架需要考虑的点

单线程或多线程
任务延时时是丢失还是继续延时
串行还是并行
异常是否影响

四：java有哪些定时任务的框架

>单机

- timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程

- ScheduledExecutorService：相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间

- spring定时框架：配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器

优点:简单
缺点:无法高可用，即节点挂了，任务不能跑

>集群

- Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能

优点:保证高可用，即节点挂了，其它节点仍然可以替代
缺点:同一次任务促发只能一个节点执行，其它节点将不执行任务，性能低，浪费资源

>分布

- TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
- elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2，并且可以支持云开发
- Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上，实现正真的弹性

优点:可以实现高可用和高性能，将任务分片，分配到多个节点执行，并且支持弹性伸缩，节点可以动态增加删除
缺点:复杂，依赖第三方分布式协调组件

五：学习使用 elastic-job

技术难点实现剖析:

实现解析