Quartz调度引擎基于MySQL的高可用架构调度延迟分析与解决方案

1、Quartz默认使用的高可用架构

在Quartz的官方文档中，介绍了一种默认的高可用架构，基于数据库实现。该方案中，多台Quartz服务器连接同一个数据库，单台服务器每次调度检索并锁定一批Trigger用于触发，锁定过程中将先从QRTZ_LOCKS表中获取一把全局排他锁TRIGGER_ACCESS，因此多个服务器在获取Trigger这一过程只能串行进行，各服务器轮流获取Trigger，直至所有需要触发的Trigger都被获取完毕，完成触发过程。

2、调度延迟分析

现象： 当同一时刻触发的定时任务过多（1500+）时，部分任务的触发时间出现非常明显的延迟（10s+），并且延迟时间呈现出调度批次内相近，批次间递增的情况，同时从使用的MySQL观察到在QRTZ_LOCKS表的TRIGGER_ACCESS这条数据上锁竞争非常激烈（400+查询同时抢一把锁）。
尝试的方案： 调整批量参数，未能解决，批量增大，则单次获取Trigger数量增加、耗时增加，位于后面批次的调度延迟增加。批量减小，单次获取Trigger数量减少、耗时减少，但批次增加，延迟累积导致位于后面的批次延迟增加。
疑惑： 即使是第一批次的调度延迟都可以达到10s以上，为什么从MySQL获取/更新几百条数据需要这么久？为什么一次调度会出现几百次锁竞争（按理说应该是几台Quartz服务器就有几个锁竞争才对，但是事实上看并不是这样）？
分析源码找出原因：
调度逻辑主要代码位置：QuartzSchedulerThread.run()
在Quartz中，并不是只在调度获取Trigger时才去对TRIGGER_ACCESS进行加锁，而是在每个任务完成后在JobRunShell中会触发QuartzScheduler.notifyJobStoreJobComplete()，这个过程也会去对TRIGGER_ACCESS进行加锁，因此如果有任务刚好在调度时完成，就会造成锁竞争，并且激烈程度直接与同时完成的任务规模成正比，所以在同时触发的任务量很大的场景下，就出现了比较严重的调度延迟。

3、改进方案

按理说，调度过程中的加锁与任务执行完成后的加锁锁定的对象粒度应该是不一样的，前者是面向一批任务，后者是面向单个任务，这里应该是一个锁粒度过粗导致的竞争问题，尝试升级Quartz版本解决，但是在查看Quartz最新版本代码后发现，该问题依然存在，在现有的代码架构下，基于DB的高可用方案带来的调度延迟是无法消除的。

然而，要更换使用别的调度框架或者自研调度引擎成本又太高，只能想一些其他办法了。

观察发现，调度延迟主要来源于MySQL锁竞争的等待时间累积，应用程序通过MySQL锁竞争来保证一致性是性能较低的选择，因为涉及到网络通信，而使用更加轻量级的JVM锁能将耗时降低1-2个数量级，考虑到Quartz需要调度的任务数据并不多（不足1G），因此完全可以使用基于内存的JobStore进行调度，也就是使用单个Quartz实例调度所有的任务，而高可用则采用多实例+redis保证触发唯一性实现，任务更新采用多实例+MQ广播消息实现，最终调度延迟降低到5s以内，P95在1s以内。