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