什么时候使用 setTimeout 和 Cron 比较合适？

Question

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

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

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

每种做法的优缺点是什么？

把它放在上下文中：

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

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

Answer 1

使用操作系统级别的 cron 作业将不起作用，因为您只能使用 60 秒的分辨率进行检查。 因此，通过“cron job”，我认为您的意思是单个setTimeout （或synced-cron ）。 以下是一些想法：

单组超时

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

这种策略的优点是实施起来很简单。 缺点是：

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

如果您确信可以控制运行时，我会推荐此策略。 例如，如果您可以在endTime索引您的匹配项，那么在每个周期中只需要检查几个匹配项。

多个 setTimeouts

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

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

1. 实现起来可能有点棘手。 例如，您必须考虑服务器重启时会发生什么。
2. 天真的实现不会扩展到单个服务器（参见 1）。

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

---

鉴于您提出的选择，这些是我想到的权衡。 更强大的解决方案可能会涉及到流星/mongo 堆栈之外的技术。 例如，将匹配时间存储在 redis 中，然后侦听keyspace 通知。

Answer 2

老实说，这完全是个人喜好问题。

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

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

不过，这只是一种偏好。