背景

定时任务总结

差不多定时任务经历了如下几个时代(不熟悉的朋友可以看我前面的介绍)：

• quartz时代-集群部署
• scheduler和timer时代-单独部署
• tbscheduler、esjob、xxl-job时代-分布式调度

08年左右，quartz在企业级应用较多，那个时候配合数据库(oracle)建立很多张表，来实现任务的集群部署方式。基本原理，是通过数据库锁，实现任务的争用，保证某个时间段，只有一个节点执行任务。那个时候，基本做到了任务和应用不需要单独分离。只要在应用中配置好定时任务，就可以了。优点：不需要单独考虑任务的部署。缺点：实现复杂，维护成本高。

10年左右，电商经过两年多的发展，去存储过程，去函数，将所有的逻辑放在代码中实现。存储过程不多，但是都是单独部署。比较典型的就是那个时候的一号店。12年左右，开始引入分布式任务调度框架。我也就是从那个时候开始接触tbscheduler，并开始学习他，改写他。优点：任务和业务分离。单独部署。缺点：任务单独部署，不支持集群，存在单点。且需要单独维护，增加维护成本。

随后的几年，分布式任务调度框架推陈出新，这个时候大家已经不用自己造轮子了。直接拿来主义就行。任务支持集群方式部署，分布式方式调用。

定时任务注意点

这里，我想说的是，不管你的任务是分布式部署，还是单点部署，还是其他任何方式部署，有一件事情，你必须要做到位：幂等。

这里再啰嗦一句，度娘解释幂等：重复做一件事，得到的结果都是一样的。谁还不知道幂等的，可以闭门思过了。

所以，你幂等做好了，无论任务错跑了，跑挂了你要重跑了，都无所谓。因为你无论来多少次，我数据不会出错。

其次，我想说的是任务的监控。很多人不愿意写任务运行日志，就像很多人写代码，在关键地方，不想着打点日志看看效果(当然，打日志也要慎重，因为日志打多了，会影响性能)。通过日志，我们能实时监控定时任务的运行情况，并适当的增加报警和重发机制。

最后，我想告诫下年轻人：做事情一定要给自己留点余地。所以，在系统中留个后门，可以让自己手工触发。通过curl命令或者其他方式。

总结下三点：1、幂等；2、日志轨迹；3、手工入口。

设计思路

• 废话讲了很多，下来看下es-job的架构图：

这里，我们着重看下es-job-lite部分：

其实包含了如下几块：

其他的都暂时可以忽略，我们每个人都能做。都属于边缘功能。分别来解释下大概的原理：

我在想，一个完整的分布式任务调度框架，基本 也就这么多了吧。

看了上面这么多，不知道大家对分布式任务调度的思路理解的怎么样了。如果还不清楚，你就去扒人家源码吧。

• brave-dis-job设计思路大体思路一致。

• 配置中心采用zk集群。客户端用apache的curator。

• 任务的触发，简易的采用scheduler。但是对于worker的执行，采用了工厂模式。

• leader-election，这里其实没有做选举，采用的是锁的方式来搞定的。谁先争抢到了锁，谁就有权分配任务。

• 分配任务有两种方式：round-robin和平均切片的方式。由于我涉及到的系统的特殊性，我采用了平均切片的方式。

这里有一个注意点：之前在跑任务的时候，会遇到集群中的机器，启动的时间点不一致，导致其实每半个小时一次的任务，会在启动的时候，可能连续跑多次。那是和机器发布的组数有关系的。所以为了防止这种情况出现。增加了任务的执行记录，记录到zk中。如果当前有任务在跑，不再重复执行本次任务。

我们来看下zk上被写入的信息有哪些：demo1任务在启动后，会有个demo1的节点,节点下就是可以执行这个任务的机器列表。同时会有一个demo1-lock,lock下面记录下正在执行的任务数。如果这个节点下，还有子节点，本demo1任务不会再次执行。知道该节点下没有任何任务为止。

代码解析

后续迭代方向

1、任务控制台

2、通过控制台配置启动参数

3、执行日志展示

4、报警监控

5、任务的failover机制

6、更好的平台化