背景

目前在负责的一个系统，总是隔三差五出事情。核心的业务逻辑全部通过定时任务来跑，且定时任务没有做集群部署，分布式调度处理。再加上开发人员不太注意代码质量和性能，所以处处是坑。

之前和团队说过很多次，要把任务拆分出来。但是，最后他们总是以各种理由拖着没做。痛定思痛，我决定自己写一个。

可能很多人会说现在任务调度的框架那么多，比如es-job，tb-scheduler这个半成品，还有xxl-job，直接拿来用不就行了？可是我想说，你要用一个人家的东西，基本的前提就是要熟悉这个东西怎么用，各个配置代表什么意思，出了问题后，要能解决问题，如果不满足要求，要能定制。那么试问，谁能全部做到？这个学习和改造的成本有多高？所以，基于我对分布式任务调度框架的理解，写了个简单的平台。

定时任务总结

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

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

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

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

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

定时任务注意点

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

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

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

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

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

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

设计思路

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

  
  Screen Shot 2018-04-06 at 9.53.34 PM.png
  

  这里，我们着重看下es-job-lite部分：
  其实包含了如下几块：
  1、online-register
  2、scheduler-trigger
  3、leader election
  4、shared
  5、execution
  6、failover
  其他的都暂时可以忽略，我们每个人都能做。都属于边缘功能。
  分别来解释下大概的原理：
  1、online-register：注册服务节点，一般会在zk上写很多节点信息。这个一般是框架前置工作。
  2、scheduler-trigger:任务触发，单独来任务的触发方式，通过接口或者继承来实现，平台化一般都会做这种事。
  3、leader-election：分布式任务调度，要来做shard,你必须选出一个人领导者来做。这是事情就像中国的一党专政一样，共产党来安排，其他人根据安排的结果来执行就行。如果多个政党来安排，那不是天下大乱了。
  4、shared：看字面意思，我不多解释。
  5、execution：还是看字面意思。
  6、failover：这个做的不错，任务支持failover。失败了，能有备选方案，接着来完成。不过理解了思路，我们也能搞定。

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

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

• brave-dis-job设计思路

  
  Screen Shot 2018-04-06 at 10.12.05 PM.png
  

  大体思路一致。

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

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

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

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

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

我们来看下zk上被写入的信息有哪些：

Screen Shot 2018-04-06 at 10.25.48 PM.png

demo1任务在启动后，会有个demo1的节点,节点下就是可以执行这个任务的机器列表。
同时会有一个demo1-lock,lock下面记录下正在执行的任务数。如果这个节点下，还有子节点，本demo1任务不会再次执行。知道该节点下没有任何任务为止。

代码解析

brave-dis-job

后续迭代方向

1、任务控制台
2、通过控制台配置启动参数
3、执行日志展示
4、报警监控
5、任务的failover机制
6、更好的平台化