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数量减少、耗时减少，但批次增加，延迟累积导致位于后面的批次延迟增加。
疑惑： 即使