什么时候适合使用 setTimeout 与 Cron

When is it appropriate to use a setTimeout vs a Cron?

本文关键字：setTimeout Cron 什么时候      更新时间：2023-09-26

我正在构建一个使用mongo数据库的Meteor应用程序。

我有一个集合，可能有 1000 个文档需要在不同时间更新。

我是在创建时运行 setTimeouts 还是每秒运行一次并遍历每个文档的 cron 作业？

做每个都有利弊？

将其置于上下文中：

我正在建立一个在线锦标赛系统。我可以举办 100 场锦标赛，这意味着我可以举办 1000 场比赛。

每场比赛都需要在特定时间绝对结束，并且在一定条件下可以提前结束。

使用操作系统级别的 cron 作业不起作用，因为您只能使用 60 秒的分辨率进行检查。所以"cron job"，我认为你的意思是单个setTimeout(或同步 cron(。以下是一些想法：

单集超时

策略：每秒醒来并检查大量匹配项，更新已完成的匹配项。如果您有多台服务器，则可以阻止除其中一台之外的所有服务器通过 synced-cron 进行检查。

此策略的优点是易于实施。缺点是：

  1. 您最终可能会执行大量不必要的数据库读取。
  2. 您必须非常小心，确保您的处理时间不超过检查之间的时间长度(一秒(。

如果您确信可以控制运行时，我建议您使用此策略。例如，如果可以在endTime上为匹配项编制索引，则每个周期中只需检查几个匹配项。

多次设置超时

策略：在创建时或服务器开始时为每个匹配项添加一个setTimeout。每次超时到期时，请更新相应的匹配项。

此策略的优点是，它可能会删除大量不必要的数据库流量。缺点是：

  1. 实现起来可能有点棘手。 例如，您必须考虑服务器重新启动时会发生什么。
  2. 朴素的实现无法扩展到单个服务器之外(请参阅 1(。

如果您认为在可预见的未来将使用单个服务器，我建议您使用此策略。

<小时 />

这些是鉴于您提出的选择而发生在我身上的权衡。更强大的解决方案可能涉及流星/mongo堆栈之外的技术。例如，以 redis 格式存储匹配时间，然后侦听密钥空间通知。

老实说，这都是偏好问题。

我非常喜欢编写小型的独立程序，每个人都做一件事，并且做得很好。如果你也是这样，最好编写单独的程序通过 cron 定期运行。

通过这种方式，您可以保证操作系统控制的时间精度，以及易于在 Web 应用程序上下文之外调试的小型简单程序。

不过，这只是一种偏好。

相关文章：