Cron vs排队任务

Question

我的应用程序具有带有 execution_datetime 属性的 Order 模型。我想发送一些不同的通知。例如

• execution_datetime 减去12小时：通过电子邮件发送给运营商
• 执行日期时间减去3小时：向客户发送短信
• 执行日期时间加1小时：通过电子邮件发送给客户

上述时间并不严格，可以近似；轻微的偏差是可以接受的。此外，执行日期时间可以同时更改...

我不确定是使用cron还是排队的任务。我的一些想法：

Cron：

• 需要编写业务逻辑以获取适用的订单并相应执行
• 执行得到保证吗？应该实施某种数据库标志来指示已发送通知，然后获取未标记为某种故障保险的所有到期订单吗？

排队的任务：

• 任务是在创建订单时安排的吗？如果是这样，则假定执行时间已更改。如何修改预定任务？您需要在某个地方跟踪任务ID吗？
• 也许是每天大量安排适用任务的日常工作？

我期待您的建议。

Answer 1

好问题！我对这次讨论很感兴趣，让我从我的亲身经历中了解一个场景。

在我的应用程序中，我有一个Listing模型，并且他们有一个promotion_ends_at列。显然，上市促销有时会在将来结束。

因此，就像您也提到的那样，有两种方法可以做到这一点。

1. 创建列表后，我可以排队等待将来将结束列表上的促销的工作。这项工作的延迟将是升职必须结束的时间（这可能使我离开几个月）。
2. 我还可以执行一项定期执行的cron工作，以管理其促销应在特定日期结束的列表。

我们将SQS用作队列服务，并且由于SQS的最大延迟为15分钟，因此选项1不可行。然后，我们搬到Redis，在那里我们可以轻松地将延迟的工作排队很长时间。

但是，就像您也说过的那样，promotion_ends_at列可以在此期间进行更新。因此，要么必须跟踪该作业以使其出队，要么可以重新检查该作业在要执行时是否仍应运行。

例如，您可以fresh()模型并检查您的条件是否仍然有效。就我而言，我会fresh Listing，并检查promotion_ends_at是否过去。但是，这意味着我们将有很多过时的工作，无论如何都可能被丢弃。

我们最终进行了一个简单的cron作业，该作业在需要运行的那一天进行大量调度。我还认为运行延迟的作业是一种业务逻辑，也许队列不应对未来延迟太多的作业负责。