阅读 21 SEO

定时任务框架选型

定时任务框架选型

quartz

light-task-scheduler

elastic-job

xxl-job

Saturn

opencron

antares

1.quartz

quartz 的常见集群方案如下,通过在数据库中配置定时器信息, 以数据库悲观锁的方式达到同一个任务始终只有一个节点在运行

优点

· 保证节点高可用 (HA), 如果某一个几点挂了, 其他节e 点可以顶上

缺点

- 同一个任务只能有一个节点运行,其他节点将不执行任务,性能低,资源浪费

- 当碰到大量短任务时,各个节点频繁的竞争数据库锁,节点越多这种情况越严重。性能会很低下

- quartz 的分布式仅解决了集群高可用的问题,并没有解决任务分片的问题,不能实现水平扩展

结论:quartz作为开源作业调度中的佼佼者,是作业调度的首选,但是因为存在一些问题,其他的定时任务框架有好多是基于quartz做的拓展式的开发,能够体现quartz作为作业调度的作用,同事也弥补了其缺陷,所以,暂时不考虑

2.light-task-scheduler

框架概况

LTS(light-task-scheduler)主要用于解决分布式任务调度问题,支持实时任务,定时任务和Cron任务。有较好的伸缩性,扩展性,健壮稳定性而被多家公司使用。

LTS 有主要有以下四种节点:

- JobClient:主要负责提交任务, 并接收任务执行反馈结果。

- JobTracker:负责接收并分配任务,任务调度。

- TaskTracker:负责执行任务,执行完反馈给JobTracker。

- LTS-Admin:(管理后台)主要负责节点管理,任务队列管理,监控管理等。

其中JobClient,JobTracker,TaskTracker节点都是无状态的。 可以部署多个并动态的进行删减,来实现负载均衡,实现更大的负载量, 并且框架采用FailStore策略使LTS具有很好的容错能力。

LTS注册中心提供多种实现(Zookeeper,redis等),注册中心进行节点信息暴露,master选举。(Mongo or Mysql)存储任务队列和任务执行日志, netty or mina做底层通信, 并提供多种序列化方式fastjson, hessian2, java等。

LTS支持任务类型:

- 实时任务:提交了之后立即就要执行的任务。

- 定时任务:在指定时间点执行的任务,譬如 今天3点执行(单次)。

- Cron任务:CronExpression,和quartz类似(但是不是使用quartz实现的)譬如 0 0/1 * * * ?

支持动态修改任务参数,任务执行时间等设置,支持后台动态添加任务,支持Cron任务暂停,支持手动停止正在执行的任务(有条件),支持任务的监控统计,支持各个节点的任务执行监控,JVM监控等等.

架构图


流程图

结论:集群部署,支持分片,git上有较完善的文档,有可视化界面,由阿里提供,具有比较完善的拓展方式,功能也较完善,但是已经三年没有维护,原则上要选择社区活跃的架构,所以不考虑

3.antares

 Antares特性

基于Quartz的分布式调度

- 一个任务仅会被服务器集群中的某个节点调度,调度机制基于成熟的Quartz,antares内部会重写执行逻辑;

并行执行

- 用户可通过对任务预分片,有效提升任务执行效率;

失效转移

- 客户端实效转移:当某个客户端实例在执行任务中宕机时,其正在执行的分片将重新由其他客户端实例执行;

- 服务器失效转移:当服务器集群中某个节点宕机时,其正在调度的任务将转移到其他节点去调度;

弹性扩容

- 客户端扩容:客户端可通过增加应用实例,提升任务执行的效率;

- 服务器扩容:服务器集群可通过增加节点,提升集群任务调度的服务能力;

进程级的应用实例

- antares通过ip+进程号标识客户端应用实例,因此支持单机多应用实例部署;

任务依赖

- antares支持树形任务依赖,当某任务执行完成后,会通知其后置任务执行;

任务报警

- antares支持基本的任务超时报警,失败报警等;

管理控制台

- 用户可通过控制台antares-tower对任务进行基本操作,如触发,暂停,监控等。

Antares架构

结论:集群部署,以zk为注册中心,支持分片,git上有较完善的文档,有可视化见面,可弹性扩容,用redis来做持久化,基本功能也完备,但是已经三年没有维护,原则上要选择社区活跃的架构,所以不考虑

4.opencron

一个功能完善真正通用的linux定时任务调度定系统,满足多种场景下各种复杂的定时任务调度,同时集成了linux实时监控,webssh,提供一个方便管理定时任务的平台.

缺点

- 仅支持 kill任务, 现场执行,查询任务运行状态 等, 主要功能是着重于任务的修改和查询上。

- 不能动态的添加任务以及任务分片。

结论:功能较简单,集群部署,文档较少,已经三年没有更新,不做考虑

5.Saturn

Saturn (任务调度系统)是唯品会开源的一个分布式任务调度平台,取代传统的Linux Cron/Spring Batch Job的方式,做到全域统一配置,统一监控,任务高可用以及分片并发处理。

Saturn是在当当开源的Elastic Job基础上,结合各方需求和我们的实践见解改良而成。

重要特性

- 支持多种语言作业,语言无关(Java/Go/C++/PHP/Python/Ruby/shell)

- 支持秒级调度

- 支持作业分片并行执行

- 支持依赖作业串行执行

- 支持作业高可用和智能负载均衡

- 支持异常检测和自动失败转移

- 支持异地容灾

- 支持多个集群部署

- 支持跨机房区域部署

- 支持弹性动态扩容

- 支持优先级和权重设置

- 支持docker容器,容器化友好

- 支持cron时间表达式

- 支持多个时间段暂停执行控制

- 支持超时告警和超时强杀控制

- 支持灰度发布

- 支持异常、超时和无法高可用作业监控告警和简易的故障排除

- 支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计

- 经受住唯品会生产800多个节点,每日10亿级别的调度考验

结论:该框架具有非常完善的功能点,基于elastic-job进行开发,拥有quartz的强大功能,基本包含初版elastic-job的基本功能点,当前更新的活跃程度一般,有非常丰富的开发文档以及部署文档,可以作为参考框架之一。

6.xxl-job

XXL-JOB是一个分布式任务调度平台,其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

特性

1.中心制

调度中心HA(中心式):调度采用中心式设计,“调度中心”自研调度组件并支持集群部署,可保证调度中心HA;

执行器HA(分布式):任务分布式执行,任务”执行器”支持集群部署,可保证任务执行HA;

2.高可用

调度中心:支持多节点部署,基于数据库行锁,在触发器的名称和执行时间相同前提下,确保仅有一个调度中心节点会执行任务下发工作。

执行器:支持多节点部署,通过调度中心选择其中的执行器,下发任务来执行。

3.策略路由

忙碌转移、故障转移、最先节点、最后节点、节点轮询、节点随机、一致性HASH、最少使用节点、最久未用节点、分片广播。

4.阻塞处理

单机串行、丢弃后续调度、覆盖之前调度。

5.故障处理

故障转移、失败重试、任务超时中断。

以上是项目的一些主要特性,还包括告警、GLUE、各种语言支持、国际化、容器化等等的特性,内容丰富,功能强大

而且相对来说简单易用,部署简单,配置简单

缺点

中心化部署,数据库行锁,性能会存在一定的瓶颈,但是对于公司比较小的流量来说,足够使用

7.elastic-job

ElasticJob 是面向互联网生态和海量任务的分布式调度解决方案,由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。 它通过弹性调度、资源管控、以及作业治理的功能,打造一个适用于互联网场景的分布式调度解决方案,并通过开放的架构设计,提供多元化的作业生态。 它的各个产品使用统一的作业 API,开发者仅需一次开发,即可随意部署。

特性

1.分布式调度

无作业调度中心节点,基于部署作业节点到达设定时间点时各自触发调度;注册中心仅用于作业注册和监控信息存储,而主作业节点仅用于处理分片和清理等功能。

2.作业高可用

提供安全的方式执行作业。将分片总数设置为1,并使用多于1台的服务器执行作业,作业将会以1主n从的方式执行。

一旦执行作业的服务器崩溃,等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好,可以保证在本次作业执行时崩溃,备机立即启动替补执行。

3.资源利用率

提供最灵活的方式,最大限度的提高执行作业的吞吐量。将分片项设置为大于服务器的数量,最好是大于服务器倍数的数量,作业将会合理的利用分布式资源,动态的分配分片项。

4.分片与业务解耦

不直接提供数据处理的功能,框架只会将分片项分配至各个运行中的作业服务器,开发者需要自行处理分片项与真实数据的对应关系。

同时可个性化参数(shardingItemParameter),分片项匹配对应关系,用于将分片项的数字转换为更加可读的业务代码。

5.丰富的策略与扩展

提供了很多默认的策略机制,并且提供了SPI的扩展点,便于高级用户进行扩展。

缺点

由于框架比较大,而且接入zookeeper,相对而言比较复杂,需要理解,而且提供的配置项比较多,需要合理使用,正确使用。

比较分析

通过以上几个框架的描述来看,首先从社区活跃度来说,前四个已经有多年未更新,不再考虑范围内,然后从高可用、一致性、故障转移、任务分片、日志追溯、异常告警等来说,后面三种框架基本支持,由于Saturn是基于elasticjob进行二次开发,而且最近的更新时间在三个月,不做考虑,只在elastic-job和xxl-job之间进行考虑。

elastic-job和xxl-job

两个从功能来说基于相同,不同的是中心化和分布式,xxl-job目前也在往分布式发展,从性能来说,达到一定的两级来说,分布式的优势会更大,但是目前公司的流量来说,两者都已经满足,此处没有进行性能分析,从github上作者的回复来看,xxl-job支持5000个并发,已经足够满足业务需求。

从社区来说,xxl-job是个人维护的项目,虽然大众点评已经对其二次开发Ferrari,但是xxl-job基本属于个人维护,而elastic-job属于apache shardingsphere子项目,属于apache旗下,未来肯定会有更多的人参与进开发,社区活跃度优于xxl-job

从框架技术来说,elastic-job引入了很多中间件和技术,相对于xxl-job来说,对于初级业务开发人员来说,理解上会相对难一点。

从文档丰富程度来说,elastic-job只提供了部分比较关键的技术点,对于很多细节需要从源码着手,xxl-job提供了完备的技术文档,而且架构相对简单,便于入手。

综上考虑,为了后续业务发展万一达到一定量级,xxl-job难以支持或者错误率过高的情况下,而且elasticjob足够活跃的社区,同时,对于初级业务开发而言,不需要完全理解,所以,目前选择elasticjob来作为未来java定时任务框架

作者:skipper_sj

原文链接:https://www.jianshu.com/p/f00784bb24db

文章分类
后端
文章标签
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 gxwowoo@163.com 举报,一经查实,本站将立刻删除。
相关推荐