java quartz 性能_[译]如何优化Quartz调度器性能

大家好，又见面了，我是你们的朋友全栈君。

译文由杰微刊兼职译者刘晓冬翻译，杰微刊审校及发布。

Quartz是一个流行的Java应用开源作业调度库。eBay在自己的很多项目中用它来调度作业。

Quartz在低负载时运行良好，但在高负载时会遇到问题。许多触发器会失效，导致执行线程无法得到任务，大量作业阻塞在触发器表中。

所以我们必须进行性能调优。本章描述我们是如何逐步解决问题并优化Quartz的。

问题在哪？

1.Quartz作业不能被调度和执行。

2.许多作业在simple_triggers表中等待执行，但一些作业在fired_triggers中。这些简单触发器应当设置REPEAT_INTERVAL，表明它们是重复作业。

TIMES_TRIGGERED表示该作业被触发的次数

3.日志文件中有大量的“Handling the first 20 triggers that missed their scheduled fire-time …”(处理错过调度触发时间点的前20个触发器)

4.数据库session增加，许多session等待在“SELECT * FROM qrtz_LOCKS WHERE SCHED_NAME = ‘{SCHED_NAME}‘ AND LOCK_NAME = ‘TRIGGER_ACCESS’ FOR UPDATE”。

什么是触发器失效？

在我们能理解为什么发生之前，先来看看触发器失效。这是来自Quartz官方网站的解释：

触发器失效发生在一致性触发器,因为调度器关闭而错过触发时间点，或者因为Quartz线程池中没有可执行作业的线程时。不同的触发器类型有不同的失效指令。默认地，他们使用一种“智能策略”指令—该指令拥有基于触发器类型和配置的动态行为。当触发器开始时，它搜索失效的一致性触发器，并根据配置的失效指令更新每一个触发器。当你开始在自己的项目中使用Quartz时，你应该先熟悉那些给定类型定义的失效指令，并在JavaDoc中给予解释。关于失效指令更详细的信息将会在每一个触发器类型的辅导中给出。

例如，有一个10秒间隔的触发器，以“0秒”为时间戳。在第“0秒”，它通过QuartzSchedulerThread把自己传递给ExecuteThread执行，并把NEXT_FIRE_TIME设定为“10秒”。不幸的是它耗时超过60秒，没有在10秒之内完成，于是错过了“10秒”，“20秒”，“60秒”等触发点。

“70秒”后，MisfireHandler发现它失败了，所以NEXT_FIRE_TIME应该被设置为“80秒”。这就是重复简单触发器的“智能策略”指令。

为什么要触发器访问锁？

Quartz支持集群，所以我们可以在集群中配置多实例。它需要使用数据库锁来协调在triggers和fire_triggers表中的更新。Quartz使用MySQL中标准行级锁“SELECT * FROM … FOR UPDATE”。

图片有助于理解触发器访问锁。

1、如果一个新作业要在triggers表中存储，它必须在LockOnInsert 为真(默认值)时获得TRIGGER_ACCESS。

2、QuartzSchedulerThread 也需要在它得到触发器并触发后拿到锁。

3、MisfiredHandler拿到TRIGGER_ACCESS用以恢复失效触发器并为失效触发器更新NEXT_FIRE_TIME。

当大量触发器失效时，系统会恶化

我们在产品中多次目睹这样的问题。以下是细节：

1.一个实例只有几个执行的作业。

2.一旦失效发生，减少实例数量可以帮助系统恢复。

基于日志和数据库信息，我们通过以下几步在本地复现了问题：

1.在本地安装MySQL数据库。

2.我们从Quartz的使用案例中复制MisfireExample

3.我们改变了配置以使Quartz使用MySQL数据库。

4.我们修改MisfireExample支持多实例，以便于我们可以在本地运行多实例。

5.我们将系统设置为每500毫秒生成一些触发器重复执行3秒间隔的触发器5遍。

做了这些更改后运行MisfireExample实例更容易复现问题。下面我们可以看到和产品中一样的问题。

1.大量触发器在simple_triggers表中堆积。

2.一些作业在fired_triggers表中触发。

3.大量失效信息打印在控制台。

4.许多MySQL sessions 等待在“SELECT * FROM qrtz_LOCKS WHERE SCHED_NAME = ‘SCHED_NAME’ AND LOCK_NAME = ‘TRIGGER_ACCESS’ FOR UPDATE”.

5.停止新触发器的存储无助于恢复触发器

6.停止3或4个实例增加了有效触发器。系统将在执行更多作业时恢复正常。

在第5步中，作业生成器在每个实例中每分钟只生成两个触发器。即使生成频率很低，系统也没有恢复。这意味着StoreJobAndTriggers在改场景中不是关键因素。问题在于MisfireHandler和QuartzSchedulerThread竞争TRIGGER_ACCESS锁。每一个实例都有一个MisfireHandler和QuartzSchedulerThread。

你可能也注意到打印的失效信息，约每秒打印一次。这说明它每次更新20行约耗时1秒。

另一个事实是每次QuartzSchedulerThread拿到TRIGGER_ACCESS锁后获取一个触发器。和MisfireHandler的速度比起来，它是一种高速操作。

下图表明了为什么少实例比多实例在遇到失效问题时更好。

更少的实例意味着QuartzSchedulerThread有更多的机会拿到锁。