xxl-job原理简介（转自阿里云）

 

一、概述

在平时的业务场景中，经常有一些场景需要使用定时任务，比如：

• 时间驱动的场景：某个时间点发送优惠券，发送短信等等。
• 批量处理数据：批量统计上个月的账单，统计上个月销售数据等等。
• 固定频率的场景：每隔5分钟需要执行一次。

所以定时任务在平时开发中并不少见，而且对于现在快速消费的时代，每天都需要发送各种推送，消息都需要依赖定时任务去完成，应用非常广泛。

二、为什么需要任务调度平台

在Java中，传统的定时任务实现方案，比如Timer，Quartz等都或多或少存在一些问题：

• 不支持集群、不支持统计、没有管理平台、没有失败报警、没有监控等等

而且在现在分布式的架构中，有一些场景需要分布式任务调度：

• 同一个服务多个实例的任务存在互斥时，需要统一的调度。
• 任务调度需要支持高可用、监控、故障告警。
• 需要统一管理和追踪各个服务节点任务调度的结果，需要记录保存任务属性信息等。

显然传统的定时任务已经不满足现在的分布式架构，所以需要一个分布式任务调度平台，目前比较主流的是elasticjob和xxl-job。

elasticjob由当当网开源，目前github有6.5k的Star，使用的公司在官网登记有76家。

跟xxl-job不同的是，elasticjob是采用zookeeper实现分布式协调，实现任务高可用以及分片。

三、xxl-job和elasticjob的区别

实际上更多公司选择xxl-job，目前xxl-job的github上有15.7k个star，登记公司有348个。毫无疑问elasticjob和xxl-job都是非常优秀的技术框架，接下来我们进一步对比讨论，探索一下为什么更多公司会选择xxl-job。

首先先介绍一下xxl-job，这是出自大众点评许雪里(xxl就是作者名字的拼音首字母)的开源项目，官网上介绍这是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。跟elasticjob不同，xxl-job环境依赖于mysql，不用ZooKeeper，这也是最大的不同。

elasticjob的初衷是为了面对高并发复杂的业务，即使是在业务量大，服务器多的时候也能做好任务调度，尽可能的利用服务器的资源。使用ZooKeeper使其具有高可用、一致性的，而且还具有良好的扩展性。官网上写elasticjob是无中心化的，通过ZooKeeper的选举机制选举出主服务器，如果主服务器挂了，会重新选举新的主服务器。因此elasticjob具有良好的扩展性和可用性，但是使用和运维有一定的复杂。

xxl-job则相反，是通过一个中心式的调度平台，调度多个执行器执行任务，调度中心通过DB锁保证集群分布式调度的一致性，这样扩展执行器会增大DB的压力，但是如果实际上这里数据库只是负责任务的调度执行。但是如果没有大量的执行器的话和任务的情况，是不会造成数据库压力的。实际上大部分公司任务数，执行器并不多(虽然面试经常会问一些高并发的问题)。

相对来说，xxl-job中心式的调度平台轻量级，开箱即用，操作简易，上手快，与SpringBoot有非常好的集成，而且监控界面就集成在调度中心，界面又简洁，对于企业维护起来成本不高，还有失败的邮件告警等等。这就使很多企业选择xxl-job做调度平台。

四、xxl-job原理

下面简单地说一下xxl-job的架构，我们先看官网提供的一张架构图来分析。

从架构图可以看出，分别有调度中心和执行器两大组成部分

• 调度中心。负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。支持可视化界面，可以在调度中心对任务进行新增，更新，删除，会实时生效。支持监控调度结果，查看执行日志，查看调度任务统计报表，任务失败告警等等。
• 执行器。负责接收调度请求，执行调度任务的业务逻辑。执行器启动后需要注册到调度中心。接收调度中心的发出的执行请求，终止请求，日志请求等等。

接下来我们看一下xxl-job的工作原理。

• 任务执行器根据配置的调度中心的地址，自动注册到调度中心。
• 达到任务触发条件，调度中心下发任务。
• 执行器基于线程池执行任务，并把执行结果放入内存队列中、把执行日志写入日志文件中。
• 执行器的回调线程消费内存队列中的执行结果，主动上报给调度中心。
• 当用户在调度中心查看任务日志，调度中心请求任务执行器，任务执行器读取任务日志文件并返回日志详情。