quartz集群模式任务触发分析(三)

源码回顾

JobStoreSupport

任务的存储类,这里面包含了上面提到的两个比较核心的方法

acquireNextTriggers

上面看到的是触发器的获取详细实现,如果每次获取的maxCount大于1 ,那么就会使用悲观锁,防止任务在集群状态下被重复获取,默认maxCount=1 , 这也就导致了,在默认的集群模式下,如果不做这个配置,在并发状态下,就会有出现任务被重复获取,会产生任务被重复触发的情况。

triggersFired

在主线程里面调用如下:

该方法做了以下工作:

1.获取trigger当前状态

2.通过trigger中的JobKey读取trigger包含的Job信息

3.将trigger更新至触发状态

4.更新数据库中trigger的信息,包括更改状态至STATE_COMPLETE,及计算下一次触发时间.

5.返回trigger触发结果的数据传输类TriggerFiredBundle

从该方法返回后,trigger的执行过程已基本完毕.回到执行quratz操作规范的executeInNonManagedTXLock方法,将数据库锁释放.

trigger触发操作完成

总结:

简单地说,quartz的分布式调度策略是以数据库为边界资源的一种异步策略.各个调度器都遵守一个基于数据库锁的操作规则保证了操作的唯一性.

同时多个节点的异步运行保证了服务的可靠.但这种策略有自己的局限性,集群特性对于高cpu使用率的任务效果很好,但是对于大量的短任务,

各个节点都会抢占数据库锁,这样就出现大量的线程等待资源.这种情况随着节点的增加会越来越严重.

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180619G0JFXJ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券