Java主流定时任务解决方案横向对比分析有哪些？

本文共计2578个文字，预计阅读时间需要11分钟。

目录+ 引用 + Crontab + 目标定位 + 使用方式 + 实现原理 + 案例分析+ Spring Task + 目标定位 + 使用方式 + 实现原理 + 案例分析+ ElasticJob + 目标定位 + 使用方式 + 实现原理 + 案例分析+ XXLJob + 目标定位 + 使用方式 + 实现原理 + 案例分析

目录

• 引言
• Crontab
• 目标定位
• 使用方式
• 实现原理
• 方案分析
• Spring Task
• 目标定位
• 使用方式
• 实现原理
• 方案分析
• ElasticJob
• 目标定位
• 使用方式
• 实现原理
• 方案分析
• XXLJob
• 目标定位
• 使用方式
• 实现原理
• 方案分析
• Serverless Job
• 目标定位
• 使用方式
• 实现原理
• 方案分析
• 总结

引言

定时任务作为一种按照约定时间执行预期逻辑的通用模式，在企业级开发中承载着丰富的业务场景，诸如后台定时同步数据生成报表，定时清理磁盘日志文件，定时扫描超时订单进行补偿回调等。程序开发人员在定时任务领域有着诸多框架和方案可供选择，并借此快速实现业务功能实现产品上线。本文将就当前主流定时任务解决方案进行介绍和分析，期望可以在企业技术选型和项目架构重构时作为参考。

Crontab

目标定位

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

使用方式

crontab 命令语法：

crontab [-u username] [-l | -e | -r ] 参数： -u : 只有root用户才能进行这个任务，编辑某个用户的crontab -e : 编辑 crontab 的工作内容 -l : 查阅 crontab 的工作内容 -r : 移除所有的 crontab 的工作内容

配置文件示例：

* * * * * touch ~/crontab_test * 3 * * * ~/backup 0 */2 * * * /sbin/service 127.0.0.1:8080/xxl-job-admin xxl.job.accessToken= xxl.job.executor.appname=xxl-job-executor-sample xxl.job.executor.address= xxl.job.executor.ip= xxl.job.executor.port=9999 xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler xxl.job.executor.logretentiondays=30

通过 bean 模式方法形式创建任务和前后回调的使用方式如下：

@XxlJob(value = "demoJobHandler2", init = "init", destroy = "destroy") public void demoJobHandler() throws Exception { int shardIndex = XxlJobHelper.getShardIndex(); int shardTotal = XxlJobHelper.getShardTotal(); XxlJobHelper.log("分片参数：当前分片序号 = {}, 总分片数 = {}", shardIndex, shardTotal); } public void init(){ logger.info("init"); } public void destroy(){ logger.info("destory"); }

创建任务完成后，需要在控制台上配置任务的执行策略：

实现原理

XXLJob 实现上将调度系统与任务解耦，其自研调度器负责管理调度信息，按照调度配置发出调度请求，支持可视化、简单且动态的管理调度信息，自动发现和路由，调度过期策略，重试策略，支持执行器 Failover。执行器负责接收调度请求并执行任务逻辑，并接收任务终止请求和日志请求，负责任务超时，阻塞策略等。调度器和执行器通过 restful api 进行通信，调度器本身无状态支持集群部署，提升调度系统容灾和可用性，通过 mysql 维护锁信息和持久化。执行器无状态支持集群部署，提升调度系统可用性，同时提升任务处理能力。

XXLJob 一次完整的任务调度通讯流程：首先调度中心向执行器内嵌 Server 发送 http 调度请求，然后执行器执行对应的任务逻辑，待任务执行完成或超时后执行器发送 http 回调向调度中心返回调度结果。

方案分析

XXLJob 在开源社区广泛流行，凭借其简单的操作和丰富的功能已在多家公司投入使用，可以较好的满足生产级别的需求，但下面的一些痛点需要改进：

• 需要依赖外置 DB，增加了数据库的使用成本和维护复杂度
• 依赖 DB 锁保证集群分布式调度的一致性,当短时任务量不断增多将对 db 造成较大压力，成为性能瓶颈
• 相较于无中心模式需要额外部署调度器，调度器和执行器均需要常驻同时为保证高可用均至少两台，当无任务执行时造成不必要的资源成本浪费

Serverless Job

Serverless 作为云计算的最佳实践和未来演进趋势，其全托管免运维的使用体验和按量付费的成本优势使得其在云原生时代备受推崇。SAE （Serverless 应用引擎）Job 作为首款面向任务的 Serverless PaaS 平台，提供传统的用户体验。当前聚焦支持单机、广播、并行分片模型的任务，同时支持事件驱动、并发策略和超时重试等诸多特性，提供低成本、多规格、高弹性的资源实例来满足短时任务的执行。

对于使用上述所有方案的存量应用，SAE （Serverless 应用引擎） Job 在兼容功能体验的同时支持零改造无感迁移，无论用户使用的是 Crontab，Spring Task，还是 ElasticJob, XXLJob，均可将代码包或者镜像直接部署到 SAE （Serverless 应用引擎） Job中，直接升级成为 Serverless 架构, 从而即刻拥有 Serverless 所带来的技术上的优势，节省资源成本和运维成本。

对于运完即停的程序，无论是 Java，还是 Shell，Python，Go，Php 均可以直接部署到 SAE （Serverless 应用引擎） Job 中, 从而即刻拥有白屏化管控，全托管免运维的完备体验以及开箱即用的可观测功能。

SAE （Serverless 应用引擎）Job 底层为多租 Kubernetes，使用神龙裸金属安全容器、VK 对接 ECI 两种方式提供集群计算资源。用户在 SAE（Serverless 应用引擎）中运行的任务会映射到 Kubernetes 中相应的资源。其中多租能力是借助系统隔离、数据隔离、服务隔离和网络隔离实现租户间的隔离。SAE （Serverless 应用引擎）Job 通过 Event Bridge 作为事件驱动源,在支持丰富调用方式的同时避免了 Kubernetes 内置定时器不保证准时触发以及精度时区上的问题。同时不断完善 Job 控制器的企业级特性，新增自定义分片，注入配置，差异化 GC，sidecar 主动退出，实时日志持久化，事件通知等机制。并借助 Java 字节码增强技术接管任务调度，实现通用的 Java 目标框架的零改造 Serverless 化。使用 KubeVela 软件交付平台作为任务发布和管理的载体，以任务为中心，以开源开放的标准，通过声明式的方式完成整个云原生交付。SAE （Serverless 应用引擎）Job 将持续优化 etcd 以及调度器在短时任务高并发创建场景下的效率以及实例启动的极致弹性能力，结合弹性资源池保证任务调度的低延迟和高可用。

SAE （Serverless 应用引擎）Job 解决了上述定时任务解决方案的各种痛点，用户无需关注任务的调度和集群资源，无需部署的额外的运维依赖组件，也无需自建一整套监控告警系统，同时更重要的是无需云主机 7*24h 常驻，在低资源利用率的环境下持续消耗闲置资源。

SAE （Serverless 应用引擎）Job 相较于传统定时任务解决方案提供了三大核心价值：

• 完备全托管：提供了一站式全托管的管理界面，其任务生命周期管理、可观测性开箱即用，用户可以低心智负担、零成本地学习使用 SAE （Serverless 应用引擎）。
• 简单免运维：屏蔽了底层资源，用户只需关注其核心的业务逻辑开发，无需操心集群可用性、容量、性能等方面的问题。
• 超高性价比：采用按需使用、按量付费的模式，只有任务执行业务逻辑时才会拉起收费，其余时间不收取任何费用，极大节省了资源的成本开销。

总结

本文对主流定时任务解决方案（Crontab, Spring Task, ElasticJob, XXLJob, Serverless Job）的目标定位、使用方式、实现原理进行了阐述，同时就企业密切关注的功能体验，性能成本方面的问题进行横评分析。最后期望大家选用 Serverless Job，感受其对传统任务所带来的新变革。

以上就是java开发主流定时任务解决方案全横评详解的详细内容，更多关于java 主流定时任务解决方案的资料请关注自由互联其它相关文章！