首页 > 编程知识 正文

quartz分布式定时任务原理,轻量级分布式定时任务

时间:2023-05-04 07:32:02 阅读:13066 作者:4368

http://www.Sina.com/http://www.Sina.com /

为什么需要定时任务,首先考虑以下业务场景的解决方案:

支付系统每天凌晨1点进行批款,进行一天清算,每月1日进行上月清算

电子商务1点抢购,商品价格8点1点开始打折

12306购票系统在订单支付30分钟以上未成功时,进行回收处理

商品成功发货后,需要通过邮件提醒客户

类似的业务场景非常多,怎么解决?

在很多业务场景中,我们需要在某个特定的时间点进行任务。 定时任务要解决的就是这样的业务场景。 通常,系统可以使用消息收发来代替一些定时任务,两者有很多相似之处并且可以彼此替换场景。

例如,如果上述成功发货并通过邮件通知了客户的业务场景,我们可以在成功发货后,将MQ消息发送到队列中,然后消耗MQ消息发送邮件。

但是,有些场景无法更换。

时间驱动/事件驱动:内部系统通常可以按时间驱动,但如果涉及外部系统,则只能使用时间驱动。 害怕收取外部网站价格的情况下,每小时爬一次

批量处理/项目符号处理:批量处理堆积的数据更有效率,在不需要实时性的情况下比消息中间件更有优势。 而且,也有只能批量处理的商业逻辑。 例如,移动每月结算我们的电话费

实时/非实时:消息中间件可以实时处理数据,但可能不需要实时,如vip升级

系统内部/系统解耦:定时任务调度通常位于系统内部,消息中间件可在两个系统之间使用

哪个计时器任务的框架是独立的timer :可以在计时器类中设置指定的计时器任务。 TimerTask类是定时任务类,用于实现Runnable接口。 如果不异常检查缺点,线程将中止

ScheduledExecutorService :相对延迟或周期安排为定时任务,具有没有绝对日期或时间的缺点

spring时间框架:配置简单的功能很多,如果系统是单机使用的,可以优先使用spring计时器

分布式队列: Java事实上的定时任务标准。 但是,Quartz关注的是计划任务而不是数据,没有针对数据处理进行定制的流程。 Quartz可以基于数据库实现作业的高可用性,但缺少分布式并行调度功能

TBSchedule :蚂蚁的初始开源分布式任务调度系统。 代码有点旧,使用timer而不是线程池来运行任务调度。 众所周知,timer在处理异常情况时有缺陷。 另外,TBSchedule工作类型是单一的,只有一种获取/处理数据的模式。 还有,文档丢失得很严重

elastic-job :当时开发的灵活的分布式任务调度系统。 功能丰富、强大,采用zookeeper实现分布式协调,实现任务的高可用性和分片化。 目前版本2.15,支持云开发。 这是我写的一系列教程。 可以用Java技术堆栈公众号搜索阅读。

Saturn :是唯品会自主开发的分布式定时任务调度平台,基于elastic-job版本1开发,可以很好地部署到docker容器中。

xxl-job:是2015年推出的分布式任务调度平台,以开发快速、学习简单、重量轻、易于扩展为核心的设计目标。

分布式任务调度系统比较参与比较的可选系统方案: elastic——job (以下简称E-Job )和xxX-Job (以下简称x-job )

项目背景和社区力量X-Job :大众点评公司员工sdsp,贡献者3人github有2470star,1015fork | QQ讨论组6个|在使用的40多家公司注册|文档齐全

E-Job :互联网开源,贡献者17人github为2524star、1015fork | QQ讨论群1个、源代码讨论群1个|使用的50多家公司注册|文档齐全|清晰的发展计划

集群部署点击关注公众号,实用技术文章

支持执行器集群部署,提高调度系统可用性,同时提高任务处理能力。 集群部署的唯一要求是确保集群中每个执行器的配置项目xxl.job.admin.addresses/调度中心地址"一致,执行器根据该配置进行自动注册执行器等操作

及时了解

作业注册中心:基于Zookeeper及其客户端Curator实现的全局作业注册控制中心。 用于注册、控制和协调分布式作业的执行。

部署多节点时的任务不能重复执行X-Job。 使用基于Quartz数据库的分布式功能

E-Job :当您将任务划分为n个任务项时,每个服务都会执行各自分配的任务项。 当新服务器加入群集或现有服务器脱机时,elastic-job会在下一次任务开始之前触发任务的重新切片,同时保持此任务的执行。

日志可跟踪X-Job :支持,有日志查询界面

E-Job :可以通过事件订阅方式处理调度过程中的重要事件,并将其用于查询、统计信息和监视。 艾拉

stic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。

监控告警

X-Job:调度失败时,将会触发失败报警,如发送报警邮件。

任务调度失败时邮件通知的邮箱地址,支持配置多邮箱地址,配置多个邮箱地址时用逗号分隔

E-Job:通过事件订阅方式可自行实现

作业运行状态监控、监听作业服务器存活、监听近期数据处理成功、数据流类型作业(可通过监听近期数据处理成功数判断作业流量是否正常,如果小于作业正常处理的阀值,可选择报警。)、监听近期数据处理失败(可通过监听近期数据处理失败数判断作业处理结果,如果大于0,可选择报警。)

弹性扩容缩容

X-Job:使用Quartz基于数据库的分布式功能,服务器超出一定数量会给数据库造成一定的压力

E-Job:通过zk实现各服务的注册、控制及协调

支持并行调度

X-Job:调度系统多线程(默认10个线程)触发调度运行,确保调度精确执行,不被堵塞。

E-Job:采用任务分片方式实现。将一个任务拆分为n个独立的任务项,由分布式的服务器并行执行各自分配到的分片项。

高可用策略

X-Job:“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行;

E-Job:调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-Scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-Scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群,集群中只有一个调度器实例提供服务,其他实例处于”待命”状态。当该实例失败时,集群会选举剩余实例中的一个来继续提供服务。

失败处理策略

X-Job:调度失败时的处理策略,策略包括:失败告警(默认)、失败重试;

E-Job:弹性扩容缩容在下次作业运行前重分片,但本次作业执行的过程中,下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。

动态分片策略

X-Job:分片广播任务以执行器为维度进行分片,支持动态扩容执行器集群从而动态增加分片数量,协同进行业务处理;在进行大数据量业务操作时可显著提升任务处理能力和速度。

执行器集群部署时,任务路由策略选择”分片广播”情况下,一次任务调度将会广播触发对应集群中所有执行器执行一次任务,同时传递分片参数;可根据分片参数开发分片任务;

E-Job:支持多种分片策略,可自定义分片策略

默认包含三种分片策略:基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、根据作业名的哈希值对Job实例列表进行轮转的分片策略,支持自定义分片策略

elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配,如下三种情况都会触发主节点上的分片算法执行:a、新的Job实例加入集群 b、现有的Job实例下线(如果下线的是leader节点,那么先选举然后触发分片算法的执行) c、主节点选举”

和quartz框架对比

调用API的的方式操作任务,不人性化;

需要持久化业务QuartzJobBean到底层数据表中,系统侵入性相当严重。

调度逻辑和QuartzJobBean耦合在同一个项目中,这将导致一个问题,在调度任务数量逐渐增多,同时调度任务逻辑逐渐加重的情况加,此时调度系统的性能将大大受限于业务;

Quartz关注点在于定时任务而非数据,并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用,但缺少分布式并行调度的功能。

综合对比

总结和结论
共同点:

E-Job和X-job都有广泛的用户基础和完整的技术文档,都能满足定时任务的基本功能需求。

不同点:

X-Job 侧重的业务实现的简单和管理的方便,学习成本简单,失败策略和路由策略丰富。推荐使用在“用户基数相对少,服务器数量在一定范围内”的情景下使用。

E-Job 关注的是数据,增加了弹性扩容和数据分片的思路,以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些,推荐在“数据量庞大,且部署服务器数量较多”时使用。

附定时任务的其他方案

发货后超过10天未收货时系统自动确认收货的多种实现方式:

每天定时半夜筛选第二天 可以自动确认收货的订单,然后第二天 每10分钟 执行一次确认收货 开销不会太大吧 时间也相对精确

自动确认收货这个状态如果仅仅是让客户端看的话,等用户下一次上线的时间,做一次运算就可以了。

延迟和定时消息投递

ActiveMQ提供了一种broker端消息定时调度机制。适用于:1、不希望消息马上被broker投递出去,而是想要消息60秒以后发给消费者,2、想让消息没隔一定时间投递一次,一共投递指定的次数

RabbitMQ可以针对Queue和Message设置 x-message-tt,来控制消息的生存时间,如果超时,则消息变为dead letter。利用DLX,当消息在一个队列中变成死信后,它能被重新publish到另一个Exchange。这时候消息就可以重新被消费。

感谢阅读,希望对你有所帮助 :) 

来源:http://expectfly.com/

●【练手项目】基于SpringBoot的ERP系统,自带进销存+财务+生产功能●分享一套基于SpringBoot和Vue的企业级中后台开源项目,代码很规范!●能挣钱的,开源 SpringBoot 商城系统,功能超全,超漂亮!PS:因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。