为什么我不能在 Quartz.net 中将多个作业调度到同一个触发器？
我正在研究 Quartz.NET 来安排任务。要求之一是我希望能够将多个作业安排到同一个触发器（基本上共享一个触发器）。然而，Quartz.NET 不允许这样做。我还注意到在 Windows 任务计划程序中，您也无法共享触发器。
将多个作业映射到同一个触发器似乎是一个常见的要求。我的问题是，为什么不允许这样做？有没有理由不将多个作业安排到同一个触发器？
I am looking into Quartz.NET for scheduling tasks. One of the requirements being that I want to be able to schedule multiple jobs to the same trigger (basically sharing a trigger). However, Quartz.NET doesn't allow this. I also noticed in Windows Task Scheduler, you also cannot share triggers.
Having multiple jobs mapped to the same trigger seems like a common requirement. My question is, why is this not allowed? is there a reason NOT to to schedule multiple jobs to the same trigger?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 Quartz 中，您可以将多个触发器分配给同一个作业，因为某些调度无法由单个触发器表示。
Quartz 可能不支持反向连接（每个触发器多个作业），因为：
这会增加已经允许每个作业多个触发器的现有代码的复杂性。
每个触发器的多个作业可以通过创建复合作业轻松完成，其目的是运行其他作业。
In Quartz, you can assign multiple triggers to the same job, because some schedules cannot be represented by a single trigger.
Probably Quartz doesn't support the reverse connection (multiple jobs per trigger) because:
It would add complexity to the existing code which already allows multiple triggers per job.
Multiple jobs per trigger can easily be accomplished by creating a composite job, whose purpose would be to run other jobs.
我从来没有想到过，这看起来是一个很吸引人的想法。但我认为，这只是一个猜测，之所以做不到，与可管理性和资源有关。
可管理性：作业（或任务）是调度程序中要管理的主要实体。它可以有多个触发器。这些触发器（最好）不应相互竞争。假设您可以在作业之间共享触发器并且您想要更改触发器。很难判断您的更改是否会干扰受其影响的任何其他作业的任何其他触发器。我不认识 Quartz 的设计者，但这可能是不允许共享触发器的一个原因。它将引入横向管理层。
资源：共享触发器将促进作业在同一时刻执行。 Quartz 的线程池实际上是无限的，但显然机器资源不是无限的。当不同触发器同时被触发时，您可以通过设置它们的优先级来进行一些调整。然而，当一个触发器多次触发时，这种可能性就被消除了（或者应该发生一些自动调整）。
I never thought of it and it looks like an appealing idea. But I think, it's just a guess, that the reason why it can't be done has to do with manageability and resources.
Manageability: The job (or task) is the main entity to manage in a scheduler. It can have multiple triggers. Those triggers should (preferably) not compete one another. Suppose you could share triggers among jobs and you want to change a trigger. It would be hard to tell whether your changes interfere with any other trigger on any other job that is affected by it. I don't know the designers of Quartz, but that may be a reason for disallowing shared triggers. It would introduce a lateral management layer.
Resources: Sharing triggers would promote the execution of jobs at exactly the same moment. Quartz's thread pool is practically unlimited, but machine resources are not, obviously. When different triggers are fired at the same moment you can do some tuning by setting their priorities. However, when one trigger fires multiple times this possibility is eliminated (or some automated tuning should occur).