Spring 整合Quartz 2实现定时任务五:集群、分布式架构实现探讨

到这里,功能上我们已经全实现了。

但是有时候我们的项目不是部署在一台机器上的,而是一个集群环境,往往我们的定时任务只需要一台机器执行就够了。

那么我们怎么样来实现这种集群环境下的定时任务运行呢?

前面说的支持幂等性可以在一定程序上解决这个问题,网上有版本使用数据库加锁的方式也可以,当然,还可以借助zookeeper等方式来实现更强大的分布式锁。

我在这里主要说的方式并不直接涉及到这个集群的问题,而是讨论这个定时任务运行的架构该如何来搭建,当然集群问题将自然而然得到解决。

在我的思维中,定时任务的架构应该是这样子的,见下图:

spring-quartz-project

有一个集中管理的定时任务中心,所有的定时任务信息都在这里创建、保存并被运行,但是没有具体的业务,所有的业务都在具体的项目中,这样它的资源是非常省的。

当定时任务到了运行的时间,它的职责就是连接消息中心,通过消息中心向外发布一个的消息,可以带上运行的任务信息等参数,至于谁来消费这个消息执行业务它就不关心了。

当项目有定时任务的需求时,只需关注它本身的业务逻辑而不必去写定时任务的代码,只需要向消息中心订阅相应的消息,在接收到消息后执行业务代码即可。

这样定时任务和具体的项目基本就解耦了,当有新项目加入进来时只需要订阅一个消息就能实现定时任务。

在集群环境下,可以根据需要(一台或多台执行)设置消息的消费模式,像metaQ就支持集群中的某一台消费消息,当然,稳妥起见前面说的幂等性还是必不可少的。

这样上面说的问题是不是也得到解决了呢?

当然,具体场景还得具体分析,只有适合的才是最好的。如果项目只要二三台机器就能搞定,显然这个方案是得不尝失的

如果你有更好的想法或者方案,欢迎探讨!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值