分布式定时任务平台分析 elastic-job和xxl-job

  最近公司有要搭建一个分布式定时任务平台的需求，并把这个任务交给了我。

  首先是作了一番分析了解，http://www.expectfly.com/2017/08/15/%E5%88%86%E5%B8%83%E5%BC%8F%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1%E6%96%B9%E6%A1%88%E6%8A%80%E6%9C%AF%E9%80%89%E5%9E%8B/

  可以看到目前市面上常见的定时任务框架有以下这些

• Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
• TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
• elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
• Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
• xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展

 

   可以看到最流行的就是elastic-job和xxl-job，关于这两者理论上的对比，上述文章都有提到，可以看出来两者都是非常优秀的定时任务平台，也都能满足的需求，网上也有很多人在讨论比较两者的优劣。于是我就自己尝试的一下官网的文档和代码分别搭了一套demo，经过实际的使用和比较之后，最终选择了xxl-job，下面我结合上面那片文章说说我自己的理解和原因。

    首先说说更新和维护情况，上面那篇文章是2017年8月写得，到现在过了一年多在github上elastic-job似乎已经没有在更新了，最近一个版本2.15发布于17年7月，最近一年只合并了一个pull request，而xxl-job相对来说就活跃很多最近的一个版本2.01更新与一个月以内，github上提交的代码可以看到2.02页即将发布。因此社区的讨论的活跃程度也更高，使用的公司xxl-job也比elastic-job多了不少。之前两者的star数差不多，现在xxl-job已经高于elastic-job两千多了。

   再来说说使用的感触，elastic-job一开始设计的初衷就是面对高并发复杂业务的，就像网上一篇开发者举得例子——余额宝计算收益，其核心功能在于分片和弹性扩容。尤其是在服务器数量多，业务量大的时候也能非常好的调度，压榨服务器的性能，使用zookeeper使他具有高可用和一致性的同时有很好的可扩展性，elastic-job本身没有中心的概念，通过zookeeper的选举机制选举出主服务器，任何一台服务器都可以作为主服务器，即使主服务器挂了也可以重新选举。因此elastic-job的优势在于它具有更好的可扩展性和可用性，但是这也使得他的使用和配置上比起xxl-job更复杂一些。

  而 xxl-job的是通过一个中心式集群"调度中心”来调度多个执行器执行任务的，调度中心集群可以通过增加机器来实现高可用（HA）实际会造成一定程度上的资源浪费，调度中心通过DB锁保证集群分布式调度的一致性，这样扩展执行器会增大DB的压力，但是如果实际上这里数据库只是负责任务的调度执行。在没有那么多数量的执行器和任务的情况下是完全没问题的。执行器可以支持分布式部署，这实际上就足以满足大多数场景了。关键是原理简单实现也非常简洁，用起来也很轻便，与springboot也非常好集成。而且他的监控界面直接集成到调度中心里面，可以在监控界面直接新增任务，使用GLUE模式甚至可以直接在监控界面上做任务开发写业务代码，这点未必用得到，但是确实很方便；而elastic-job是一个单独的工程连到zk上去监控的，因此不能直接增新增任务，也不能停止执行中的任务。单独记录执行日志到数据库，然后很方便的统一管理和重发，还有失败的邮件提醒都是简单又好用的功能，对于一些常规的定时任务来说感觉应该用起来很舒服。

   综合来说，xxl-job在我看来在业务量没那么大的时候是一个更好的选择。