【发布时间】:2011-10-25 05:34:41
【问题描述】:
我想将 MySQL 用作作业队列。多台机器将生产和消耗工作。需要安排工作;有些可能每小时运行,有些每天运行,等等。
看起来相当简单:对于每个作业,都有一个“nextFireTime”列,并让工作机器使用 nextFireTime 搜索作业,将记录的状态更改为“inProcess”,然后在作业时更新 nextFireTime结束。
当一个工人默默地死去时,问题就出现了。它将无法更新 nextFireTime 或将状态设置回“空闲”。
不幸的是,作业可能会长时间运行,因此无法选择寻找已在进程中时间过长的作业的 reaper 线程。没有可用的超时值。
任何人都可以提出一种可以正确处理不可靠工作机器的设计模式吗?
【问题讨论】:
-
艰难的。是否可以要求长时间运行的作业在更新时定期更新“仍处于状态”列?并要求每 X 分钟发生一次?然后收割者可以说“如果你超过 X 分钟而没有更新,那就敲吧!”
-
或者更好的设计可能是让作业队列本身以某种方式查询作业以确定它们的状态。 (一种侦听器模型。)作业必须知道如何响应状态查询。
-
是的,我想到了。有点像心跳信号。工业控制器就是这样做的。这是可能的,但这意味着我所有的工作处理人员都必须有某种内部循环来进行更新。不是一个理想的解决方案。
-
已经有像 RabbitMQ 这样完善的任务队列服务器。为什么不使用其中之一,而不是重新发明轮子?
-
这不是您问题的答案,但请阅读这篇文章:engineyard.com/blog/2011/…
标签: mysql algorithm queue job-scheduling