分布式定时任务框架原理

分布式定时任务框架原理

1. 定时任务

定时任务非常常见，如定时清理状态、定时生成订单、定时处理日志.....，总之定时任务使用得非常之广泛，定时任务的框架也比较多，如crontab,quartz,spring-batch,elastic-job,dts,tbschedule等，框架还是比较多。今天重点介绍quartz，并将它引申到分布式环境下使用。

quartz在单机环境下支持得比较多，可以支持RAM和JDBC保存job运行相关的数据，它在分布式环境下展现得不是很好。单机下进行定时任务调度时，当数据量一大的时候，运行的job时间比较长，这时就要进行优化了。曾经遇到高峰期产生订单800万，老的逻辑运行要运行数小时，分析Job执行的情况后，发现是IO密集型 ，果断采用多线程来处理，加上使用批量插入更新、预读、去掉无用重复操作，同时硬盘换成SSD，整个优化下来提速40多倍！由之前数小时完成的任务变成在几分钟之内完成，大大的提升了运行速度。但如果数据量还在急剧增加，多线程模式下，job运行时间还会延长。

在大数据量下，处理的方法就是分片处理，多线程是单机下的分片处理，单机处理能力有限。在单机下进行任务调度存在两个问题：
1）数据量一大，存在瓶颈；
2）任务调度和任务处理放在一起，这是两个独立的部分，可以拆分开。

总结1：数据量大的任务，尤其是数据量达到千万级别，只有分片处理，别无它法(单机已经做到了极限)

2. 分布式任务调度模式设计模式

2.1 调度与任务执行拆分

下面给出两种模式：

1）quartz完成任务调度(单台，后面会引申到分布式环境下)，job被唤醒后，会向集群组内发送请求，通过反射实例化任务，请注意，发送请求的时候会携带一些额外的数据过去，假设是用取余的方式，告诉每台机器select数据时，带上这个条件去select数据，目的是数据不会被重复选择出来。

2）quartz完成任务调度(单台，后面会引申到分布式环境下)，job被唤醒后，会向集群中某一台机器发送请求，该机器接受到请求后，它就专门负责捞数据，然后通过metaq发送出去，其它节点监听metaq消息，发现是自己要处理的(job名字就是tag)，就接收消息并处理。

使用quartz的原因是它帮我们做什么时候任务要执行，由它来完成调度。

正常调度的情况下，上面两种模式都没有问题，但出了异常情况下，就会有问题，比如发送消息的机器挂掉了，则该任务只执行了一部分，如果没有良好的监控，根本就不知道Job执行有没有执行完成，这两种模式还存在优化的空间。

细心的同学，又会发现一个问题，我们的业务处理代码是放在业务机器上的，难道新增加Job还要往quartz调度的执行上提交代码吗？非也，这里使用到一个巧妙的地方，就是实现化JobDetail的时候，都写一个Job，用这个Job替换所有的Job。

2.2 解决调度单点问题

经过第一步，把调度和执行分离后，调度单点是一个问题，如果它挂了，就完蛋了。如果把它放到分布式环境下进行调度呢？分布式锁这时就发挥作用了，将上面的调度机器再部署2台(理伦上调度的机器不会多台)，Job到点被唤醒后，三台机器上的TimerExecutor Job都会进行到execute()方法里，此时这三台机器都会去抢分布式锁，谁抢到了，谁就来负责调度，惊不惊喜，用分布式锁就搞定了！

到这里了，有必要总结一下:

总结 2： 调度单点问题可以通过分布式锁来实现，调度巧妙之处用一个Job映射成多个Job。 总结 3： 定时任务处理的三步曲：取数、处理、回写，上面的两种模式对应两种取数试，一种是主动取数，第二种是被动接受数据。

3. 一种按照数据区间来完成批量任务调度执行的框架

大部分的批量任务是IO密聚型的，单台机器上执行使用多线程是会提升速度的，这里会把集群分片+单机多线程都使用上去，这样处理速度会更快。一般处理的数据集有一个范围([min(Id),max[Id]])，在调度的时候就计算出来，然后按照10w的步长进行切割，得到多个区间，再把这些区间数据放到zookeeper上去，通知节点来取数据，执行完成后把对应的区间数据删除，某个目录下没有数据了，说明整个job都执行完成了。节点拿到这个10w步长的数据，内部再按1w的步长来划分，用10个线程来跑本次任务，达到集群分片执行和单机多线程执行。

总结 4: 利用集群分片+单机多线程来提升批量任务执行的效率

4. 总结

在梳理DTS框架的基础上，总结分布式批量任务处理的思想，在实际的执行过程中，曾遇到了共享数据的问题，如何保证分配的数据间没有交集(更多的体现在多表的处理)，只能从共享的维度出发分割数据，分割出来的数据并不均匀，有共享数据是一个头疼的问题，欢迎有好想法的同学可以交流这个问题。