Java学习五分钟系列，目的是为让大家在短时间内搞清楚一项技术的概念、优缺点和适用场景，想要深入的了解，还需要投入更多的时间。

需求

为方便大家的理解，先给大家讲一个真实的需求，这是我在第二家公司的一个项目，定时任务每天凌晨执行，需求很简单：把原始的业务数据，加工处理成待发送的短信。

原始数据：姓名-小明，所在地-北京，电话-13800000000，账单最后还款日期-2018年4月30日。

加工后的数据是：亲爱的小明，您的账单最后还款日期为2018年4月30日，请提前缴费。然后把需要把这条短信发送到13800000000这个手机号上。

定时任务

定时任务框架里面，最有名的就是quartz了，相信大部分Java程序员都用过。

我们项目最开始也用的是quartz，只有一个服务器跑定时任务。但是待处理的数据越来越多，定时服务执行的时间也越来越长，终于有一天，定时任务从晚上跑到了第二天白天也没有跑完，耽误了短信的发送。

改造后的定时任务

有人就有疑问了，能不能直接把定时服务部署多套不就行了。但是部署多套quartz的话，就会出现问题：待处理的任务有可能会被重复执行。

应对这种问题，我们当时有两种处理方案：

方案一：

定时服务只部署一套，但是定时任务的工作只是提取待处理的任务。

实际的业务处理服务集群化部署，然后由定式服务提取数据后，发送给业务处理服务器进行实际的处理。

方案二：

这个是我当时自己想出的一个奇葩的方法，不过这个方案想明白了，对分布式定式服务的理解很有帮助！

• 定时任务程序部署多套，并且多套环境都是独立的IP。每套程序定时将IP写入到数据中（一分钟对表update一次，并更新时间戳）。
• 多套服务选举出一台主服务器。
• 主服务器把所有的待处理任务，尽可能平均分配给每一台服务器。（IP和待处理任务对应上，也就是每一条待处理任务只能让分配的IP处理）
• 处理任务的时候，只处理自己IP对应的任务。
• 一台服务器挂了，主服务器负责把它的IP从数据库中抹掉（三分钟没有对表进行更新的IP，删除掉），并重新分配这个IP对应的待处理任务。
• 主服务器挂了，重新选举出主服务器。

分布式定时任务

我只用过Elastic-job，所以只给大家介绍一下这个框架。

任务分片：把一个任务拆分成几个独立的任务，然后由分布式服务器分别执行一个或者多个子任务。

比如还是上面那个需求，那么可以按照【所在地】拆分任务，北京的待处理数据是一个子任务，天津的待处理数据是第二个子任务。

Elastic-Job并不直接提供数据处理的功能，实际的数据处理还是需要自己写，Elastic-Job会将分片任务分配到各个运行中的作业服务器。

其实发现了没有，Elastic-Job做的工作，就是我那个主服务器做的任务分配的工作，把所在地=北京的，分配给服务器1处理，把所在地=天津的，分配给服务器2处理；甚至包括监控每台作业服务器是否存活，挂掉一台重新分配待处理任务，也都是Elastic-Job来做的。

现在想一想，我当时做的那个方案，要是包装包装，说不定也能弄一个开源框架呢。