0

Premise: I have a calendar-like system that allows the creation/deletion of 'events' at a scheduled time in the future. The end goal is to perform an action (send message/reminder) prior to & at the start of the event. I've done a bit of searching & have narrowed down to what seems to be my two most viable choices

  • Unix Cron Jobs
  • Bree

I'm not quite sure which will best suit my end goal though, and additionally, it feels like there must be some additional established ways to do things like this that I just don't have proper knowledge of, or that I'm entirely skipping over.

My questions:

  • If, theoretically, the system were to be handling an arbitrarily large amount of 'events', all for arbitrary times in the future, which of these options is more practical system-resource-wise? Is my concern in this regard even valid?

  • Is there any foreseeable problem with filling up a crontab with a large volume of jobs - or, in bree's case, scheduling a large amount of jobs?

  • Is there a better idea I've just completely missed so far?

This mainly stems from bree's use of node 'worker threads'. I'm very unfamiliar with this concept and concerned that since a 'worker thread' is spawned per every job, I could very quickly tie up all of my available threads and grind... something, to a halt. This, however, sounds somewhat silly & possibly wrong(possibly indicative of my complete lack of knowledge here), & thus, my question.

Thanks, Stark.

4

1 回答 1

1

对于类似日历的系统，您似乎可以查询数据库以查找下一小时内发生的所有事件，然后为每个事件创建一个 setTimeout()。然后，一个小时后，再次做同样的事情。然后，在任何服务器重新启动时，再次执行相同的操作。你真的不需要担心那些不是迫在眉睫的事件。他们可以坐在数据库中，直到他们的时间前不久。您只需要一种有效的方法来查询数据库以查找即将发生的事件并为它们设置一个计时器。

WorkerThreads 是 nodejs 中相当重的项目，因为它们创建了一个完全独立的堆和一个全新的 V8 解释器实例。您绝对不希望每个事件都有一个单独的 WorkerThread。

我应该补充一点，nodejs 中的计时器是非常轻量级的项目，拥有很多计时器是没有问题的。它们只是存储在排序的链表中，并且随着列表变长，只有新计时器的插入需要更多时间（在添加到列表时进行插入排序）。没有连续的运行时开销，因为有很多计时器。事件循环，然后只检查链表中的第一项，看看是否是下一个计时器触发的时间。如果是这样，它将它从列表的头部删除并调用它的回调。如果不是，它将处理事件循环工作项的其余部分，并在事件循环中再次检查列表中的第一项。

于 2021-04-02T17:30:09.097 回答