我正在创建一个守护程序，它将运行某些计划的日志记录任务，但我担心瓶颈会产生某些点。
实际上我有一些我想要每15分钟执行一次的日志记录任务，有些我只想每30分钟执行一次，依此类推，直到每月只运行一次的任务。基本上我有一个每个时间间隔的检查列表。这些被放入队列并由线程池处理。
目前我看到任务正在运行这样的事情
15
15, 30
15, 30, 60
15, 30, 60, 120
15, 30, 60, 120, 240...
这意味着如果守护进程在00:00开始，那么在04:00之后将有五个进程同时运行，这不是它的结束。目前，这导致下一个计划运行15分钟的任务缓慢运行，并且可以访问有限的带宽量。
然而，任务在一小时内运行并不是必需的。因此，如果15分钟任务在小时运行，则30分钟可以在小时后5分钟开始，以便最小化重叠。甚至可以在四个15分钟的过程中分割两个30分钟的任务（例如00:00和00:30），以减少被“一次性”类型问题击中，但这确实让我头脑中游泳。 / p>
是否有任何众所周知的方法来管理此类问题？
答案 0 :(得分：0)
答案 1 :(得分：0)
好吧，从长远来看（正如我从你的问题中看到的那样），你将不得不寻找像quartz这样的东西。
除此之外，我还有更多关注点和建议：
使用[ScheduledExecutorService][2]来管理这些线程。即使使用ScheduledExecutorService，看起来您也希望在不同的执行时间内以不同的间隔运行它们。 SchedulewithFixedRate而不是ScheduleWithFixedDelay。
即使你实现了这样的事情，你的逻辑也会fail if your threads start to run on multiple hosts。运行每小时线程的2个主机将每30分钟有效运行一次。
我希望有一个centralized management in terms of Database来跟踪上次运行和所有内容。这与ExecutorService一起可扩展且准确。
假设您有1000个计划，在DB中创建1000行。
列有点像这样
id, P_Key
ScheduleName, AnyIdentifier for the daemon to run or task to do.
lastRunTime, lastTime it was run.
granularity, 15 mins, 30 mins etc.
您可以将CreationTime和ModificationTime作为最佳做法。