定时任务系统设计

核心提示定时任务作为一种按照约定时间执行预期逻辑的通用模式,在企业级开发中承载着丰富的业务场景,诸如后台定时同步数据生成报表,定时清理磁盘日志文件,定时扫描超时订单进行补偿回调等。程序开发人员在定时任务领域有着诸多框架和方案可供选择,并借此快速实现

作为一种按照约定时间执行预期逻辑的通用模式,调度任务承载了企业开发中丰富的业务场景,比如定时同步后台数据生成报表、定时清理磁盘日志文件、定时扫描加班订单进行补偿和回调等。

程序开发者在定时任务领域有很多框架和方案可以选择,可以快速实现业务功能和产品上线。本文将对当前主流的计时任务解决方案进行介绍和分析,希望可以作为企业技术选择和项目架构重构的参考。

克罗塔布

目标位置

Crontab作为Linux内置的可执行命令,可以根据cron表达式生成的时间,实现指定系统指令或shell脚本的执行。

使用方式

Crontab命令语法:

Crontab [-u用户名] [-l | -e | -r]参数:-u:只有根用户可以执行此任务。编辑一个用户的crontab-e:编辑crontab -l的工作内容:查看crontab -r的工作内容:删除crontab的所有工作内容。

示例配置文件:

* * * * * touch ~/crontab _ test * 3 * * * ~/backup 0 */2 * * */sbin/service httpd restart

实现原则

当Linux启动时,crond守护进程由init进程启动。cornd会每分钟检查一次/etc/crontab配置文件,看是否有任务要执行,并通过/var/log/cron文件输出调度任务的执行情况。用户可以使用Crontab命令来管理/etc/crontab配置文件。

方案分析

在Crontab用户的帮助下,快速实现简单的定时任务功能非常方便,但存在以下痛点:

定时任务被绑定到指定的linux机器上,当机器被扩展或替换时,contab需要重新配置。同时,存在单点故障风险。随着定时任务规模的增大,没有一个统一的视角来跟踪和控制任务的进度,并且很难维护功能。没有任务的超时、重试、阻塞等高级特性,所以可观测性差,很难排查和定位问题。任务是永久的,当没有任务执行时,不必要的资源成本被浪费。

春季任务

目标位置

Spring框架提供了开箱即用的定时调度功能,用户可以通过xml或者@Scheduled注释来标识指定方法的执行周期。

Spring Task支持多种任务执行模式,包括带时区配置的corn、固定延迟、固定速率等。

使用方式

代码示例如下:

@ enable scheduling @ spring boot application public类App { public static void main { spring application . run;}}@Componentpublic类my task { @ Scheduled public void test { system . out . println;} }

实现原则

Spring Task的原理是在bean初始化时,借助于:scheduledannotationbeanpostprocessor拦截@ Scheduled annotation标识的方法,根据每个方法及其注释配置构建相应的任务实例,并注册到ScheduledTaskRegistrar中。

单实例bean初始化完成后,通过afterSingletonsInstantiated的回调设置ScheduledTaskRegistrar中的调度器TaskScheduler。其底层依赖于jdk中ScheduledThreadPoolExecutor的实现,afterPropertiesSet时所有任务都添加到TaskScheduler进行调度和执行。

方案分析

借助Spring Task,用户可以通过注释快速实现指定方法的周期性执行,并支持多种周期性策略。但与crontab类似,它也有以下痛点:

默认情况下,它是单线程执行。如果前一个任务执行时间长,会导致后续任务的饥饿和拥塞。用户需要配置线程池的每个节点独立运行。存在单一风险,没有分布式协调机制。有必要考虑禁止并发执行。随着预定任务规模的增大,没有统一的视角来跟踪和控制其进度。很难维持这种功能。没有超时、重试、拥塞等高级功能,可观测性差。问题很难排除和定位。任务是永久的,当没有任务执行时是不必要的

弹性作业

目标位置

ElasticJob作为当当网的开源分布式任务框架,提供了灵活调度、资源控制、作业管理等诸多特性。它已经成为Apache Shardingsphere的一个子项目。

ElasticJob目前由两个独立的子项目组成,ElasticJob-Lite和ElasticJob-Cloud。ElasticJob-Lite定位为轻量级、去中心化的解决方案,以jar的形式为分布式任务提供协调服务;ElasticJob-Cloud使用Mesos解决方案来提供额外的服务,如资源管理、应用程序分发和进程隔离。一般来说,ElasticJob-Lite可以满足需求。

使用方式

用户需要在yaml中配置注册中心zk的地址和任务的配置信息:

elastic job:reg center:server lists:localhost:6181命名空间:elastic job-lite-spring boot jobs:simple job:elastic job class:org . Apache . sharding sphere . El astic job . lite . example . job . spring bootsimplejob cron:0/5 * * * *时区:GMT+08:00 sharding total count:3 sharding item参数:0 =北京,1 =上海,2 =广州

实现相应的接口标识相应的任务,配置监听器实现任务执行前后的回调:

公共类MyElasticJob实现simple job { @ Override public void execute { switch){ case 0://通过分片item 0 break做点什么;案例1: //通过分片item 1 break做点什么;案例2: //通过分片做点什么item 2 break//案例n:...} } }公共类MyJobListener实现elastic joblistener { @ Override public void before job executed {//做点什么...} @ Override public void afterJobExecuted {//做点什么...} @覆盖公共字符串getType { return " simpleJobListener ";}}

实现原则

ElasticJob的底层时间调度基于Quartz,需要将业务Bean持久化到底层数据表中,所以系统入侵相当严重。同时,任务被db lock抢占,不支持并行调度,不可伸缩。

ElasticJob通过数据分片的特性和用户自定义的分片参数完成横向扩展,可以将一个任务拆分成N个独立的任务项,分布式服务器可以并行执行其分配的分片项。比如一个数据库有1亿条数据,需要读出并计算。这1亿条数据可以分成10个切片。每个切片读取1000万条数据,经过计算后写入数据库。

如果有三台机器,A机分片,B机分片,C机分片,这也是相比石英最显著的优势。

在ElasticJob上,zookeeper作为注册中心进行分布式调度协调和领袖节点选举,通过注册中心临时节点的变化来感知服务器的增减。每次选举一个领导节点,服务器上线下线,碎片总数发生变化,后续的碎片都会被触发。当下一个调度任务被触发时,leader节点将对分片进行详细划分,然后每个节点从注册中心获取分片信息,作为任务的运行参数来执行。

方案分析

ElasticJob作为一种分布式任务框架,解决了上述单节点任务在任务执行过程中无法保证高可用性和高并发性的性能问题,并支持故障转移和错过作业重新执行等高级机制。但是,仍然存在以下使用中的痛点:

整体框架笨重,需要依赖外部注册中心zk,增加了至少三台服务器的使用成本和维护复杂度。随着任务量的增加,zk作为一个有状态中间件,将会成为一个性能瓶颈,可观测性较弱。需要额外引入db,配置常驻事件跟踪任务,在没有任务执行时会造成不必要的资源成本浪费。

XXLJob

目标位置

XXLJob是面向大众点评员工的开源分布式任务框架,其核心设计目标是快速开发、简单学习、轻量级、易扩展。

XXLJob具有丰富的功能,任务分片广播、超时控制、失败重试、阻塞策略等。,并通过体验友好的白屏控制台管理和维护任务。

使用方式

XXLJob分为中央调度器和分布式执行器两部分,使用时需要分别启动。当调度中心启动时,它需要配置依赖的数据库配置。

执行器需要配置调度中心的地址:

xxl . job . admin . addresses = http://127 . 0 . 0 . 1:8080/xxl-job-adminxxl . job . access token = xxl . job . executor . appname = xxl-job-executor-sample xxl . job . executor . IP = xxl . job . executor . port = 999 9xxl . job . executor . log path =/data/applogs/xxl-job/jobhandler rx

bean pattern方法创建任务和前后回调的用法如下:

@ XxlJobpublic void demoJobHandler抛出异常{ int shard index = xxljobhelper . getshardindex;int shard total = xxljobhelper . getshard total;XxlJobHelper.log} public void init { logger.info} public void destroy { logger . info;}

创建任务后,您需要在控制台上配置任务的执行策略:

实现原则

XXLJob将调度系统与任务分离。其自主开发的调度器负责管理调度信息,根据调度配置发送调度请求,支持可视化、简单、动态的调度信息管理、自动发现和路由、调度到期策略、重试策略、执行器故障转移。

执行器负责接收调度请求和执行任务逻辑,接收任务终止请求和日志请求,负责任务超时和阻塞策略。调度器和执行器通过restful api进行通信。调度器本身支持集群部署无状态,提高了调度系统的容灾性和可用性,并通过mysql维护锁信息和持久性。无状态执行器支持集群部署,提高调度系统的可用性,提高任务处理能力。

XXLJob是一个完整的任务调度的通信过程:首先调度中心向执行器的嵌入式服务器发送http调度请求,然后执行器执行相应的任务逻辑,任务完成或超时后,执行器发送http回调将调度结果返回给调度中心。

方案分析

XXLJob在开源社区广受欢迎。其操作简单,功能丰富,已在多家公司投入使用,能较好地满足生产层面的需求。但是,下面的一些棘手问题需要改进:

对外部db的依赖增加了数据库的使用成本和维护复杂度。对数据库锁的依赖保证了集群分布式调度的一致性。当短期任务量不断增加时,会给DB带来很大压力,成为性能瓶颈。与无中心模式相比,需要部署额外的调度器。为了确保高可用性,调度器和执行器需要同时驻留至少两个。当没有任务执行时,会造成不必要的资源成本浪费。

无服务器作业

目标位置

无服务器(Serverless)作为云计算的最佳实践和未来演进趋势,因其全托管免运营体验和按量付费的成本优势,在云原生时代备受瞩目。

SAE Job作为第一个面向任务的无服务器PaaS平台,提供传统的用户体验。

目前专注于支持单机、广播、并行切片模型的任务,支持事件驱动、并发策略、超时重试等诸多特性,提供低成本、多规格、高灵活性的资源实例,满足短期任务执行。

使用方式

对于使用上述所有方案的股票应用程序,SAE Job支持零转换和非归纳迁移,同时兼容功能体验。

无论用户使用的是Crontab、Spring Task、ElasticJob、XXLJob,都可以直接将代码包或映像部署到SAE Job,直接升级到无服务器架构,从而立即拥有无服务器带来的技术优势,节省资源成本和运维成本。

对于出货后停止的程序,无论是Java、Shell、Python、Go、Php都可以直接部署到SAE Job,从而立刻拥有白屏控制、全托管免操作、开箱可观察功能的完整体验。

实现原则

SAE的底层是多租约Kubernetes,通过使用神龙裸机安全容器和VK对接ECI提供集群计算资源。

SAE中用户运行的任务将被映射到Kubernetes中相应的资源。其中,多租户能力是通过系统隔离、数据隔离、服务隔离、网络隔离等手段实现租户之间的隔离。

SAE使用事件桥作为事件驱动源,不仅支持丰富的调用方法,还避免了Kubernetes内置定时器不能按时触发和精确时区的问题。

同时不断完善作业控制器的企业级特性,加入自定义切片、注入配置、差异化GC、sidecar主动退出、实时日志持久化、事件通知等机制。借助Java字节码增强技术,接管任务调度,实现通用Java目标框架的零转换无服务器。

以KubeVela软件交付平台作为任务发布和管理的载体,以任务为中心,开源开放标准,以声明的方式完成整个云原生交付。SAE Job将在短期任务高并发创建的场景下,不断优化etcd和调度器的效率,以及实例启动的极致灵活性,结合灵活的资源池,保证任务调度的低延迟和高可用。

方案分析

SAE Job解决了上述定时任务解决方案的各种痛点。用户无需关注任务调度和集群资源,部署额外的运维依赖组件,自行搭建一套完整的监控和报警系统。更重要的是,他们不需要云主机7 * 24小时驻留,在资源利用率低的环境下持续消耗闲置资源。

与传统的定时任务解决方案相比,SAE Job提供了三个核心价值:

完全托管:它提供一站式完全托管管理界面。它的任务生命周期管理和可观察性是开箱即用的,用户可以低心理负担、零成本地学习使用SAE。简单运维免维护:底层资源被屏蔽,用户只需关注其核心业务逻辑的开发,无需担心集群的可用性、容量、性能等方面。超高性价比:采用按需使用,按需付费的模式。只有任务执行业务逻辑的时候才会收费,其余时间不收费,大大节省了资源成本。

摘要

阐述了主流定时任务解决方案的目标定位、用法和实现原理,并对企业关注的功能体验和性能成本进行了横向评测分析。

最后,希望你能选择无服务器作业,感受它给传统任务带来的新变化。

原文链接:http://click.aliyun.com/m/1000350418/

本文为阿里云原创内容,未经允许不得转载。

 
友情链接
鄂ICP备19019357号-22