Triggers 石英触发器提前触发

我们在64位机器上使用quartz 2.1.5（群集，2个实例，16GB ram）。系统中大约有8000个触发器

每秒钟我们就有大约50个触发器——它们每秒都会被解雇

org.quartz.threadPool.threadCount = 50
org.quartz.scheduler.batchTriggerAcquisitionMaxCount=100
org.quartz.scheduler.idleWaitTime=15000
#org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow=0 (this is not set)

石英能够处理负载，但触发器会提前触发吗

---

batchTriggerAcquisitionMaxCount-我们是否可以将其增加到500，并将batchTriggerAcquisitionFireAheadTimeWindow保持在1000（1秒），这些配置是否有任何缺点

还有别的办法吗

通过以下配置，它似乎可以正常工作

org.quartz.threadPool.threadCount = 100
org.quartz.scheduler.batchTriggerAcquisitionMaxCount=500
org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow=1000
org.quartz.scheduler.idleWaitTime=25000

---

当quartz想要运行触发器时，它会调用此方法：

triggers = qsRsrcs.getJobStore().acquireNextTriggers(now + idleWaitTime, Math.min(availThreadCount, qsRsrcs.getMaxBatchSize()), qsRsrcs.getBatchTimeWindow());

其中：

• idleWaitTime

  是

  org.quartz.scheduler.idleWaitTime

• availhtreadcount

  是可用线程数（将小于或等于

  org.quartz.threadPool.threadCount

  ）

---

• qsRsrcs.getMaxBatchSize（）

  is

  org.quartz.scheduler.batchTriggerAcquisitionMaxCount

• qsRsrcs.getBatchTimeWindow（）

  是

  org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow

它会导致一个SQL请求，如：

SELECT * FROM TRIGGERS WHERE NEXT_FIRE_TIME <= now + idleWaitTime + qsRsrcs.getBatchTimeWindow() LIMIT Math.min(availThreadCount, qsRsrcs.getMaxBatchSize())

---

SELECT*FROM TRIGGERS WHERE NEXT_FIRE_TIME这是否意味着，由于idleWaitTime，它们无论如何都会提前被触发？或者quartz提前将它们存储在内存中，并按照计划的时间激发它们？是的，由于空闲时间，它们将始终提前运行。Quartz几乎在获取后立即启动它们（它将相应的作业作为任务添加到线程池）。因此，精度取决于空闲时间。我猜quartz不适用于精确的实时规划。如果设置batchTriggerAcquisitionMaxCount=1或threadCount=1，它也不会提前运行触发器。batchTriggerAcquisitionMaxCount=1不适用于这种负载，我们必须启用批处理来支持。我们谈论的是每秒50-100个触发器。这种行为（提前使用触发器）在我看来像是一个bug。实际上，您可以看到JobStoreSupport.acquireNextTrigger中有一个奇怪的变量“firstAcquiredTriggerFireTime”，该变量已初始化，但未使用。我在quartz.NET端口中看到，它实际上用于检查是否提前阻止运行触发器。您可以在quartz论坛上报告此情况，以便他们调查此问题。RAMJobStore也有这个未使用的变量。您可能希望尝试石英的旧版本，其中此检查仍然存在。