Node.js的工作队列?

12

我正在使用node的集群API和mongoose编写一个工作队列。我发现很多库已经存在,但是使用redis和forking。与使用集群API相比,使用forking有很好的理由吗?

编辑 现在我也发现这个:https://github.com/xk/node-threads-a-gogo - 选择太多了!

我宁愿不要将redis加入到混合中,因为我已经使用mongo。另外,我的要求非常宽松,我希望有持久性,但第一版可以没有。

问题的第二部分:目前有哪些最稳定/被广泛使用的nodejs工作队列库?


1
其中许多可能是在 Cluster 不可用时启动的,或者出于它仍被标记为“实验性”的原因而选择不使用它。完全有可能使用集群和域的工作队列实现比 fork 方法更好。 - abject_error
稳定/已使用的工作队列:zeroMQ - Geert-Jan
目前还没有 ZeroMQ 的 Node.js 绑定,我正在寻找一个支持 Node.js 的库,最好不需要单独的服务器,而且轻量级。 - mkoryak
你能详细说明一下你的使用情况吗?node-threads-a-gogo似乎有非常特定的用例。如果你的使用情况符合要求,它似乎是一个很好的选择。答案中提供的链接甚至引用了对非常特定用例的需求。最佳答案取决于你的事件循环涉及的内容以及它将在哪种类型的架构上运行... - MobA11y
3个回答

8
我想跟进一下这个问题。我的解决方案最终是创建一个自定义的集群实现,其中我的一些集群工作程序是专门用于工作的(即它们只有处理工作的代码)。
我使用agenda进行作业调度。
类似于Cron类型的作业由集群主节点进行调度。其余的作业在非工作程序集群中按需创建。(例如验证电子邮件等)
在此之前,我使用了kue,但放弃了它,因为我的应用程序的其余部分使用mongodb,而我不喜欢仅为作业调度而使用redis。

7

1
非常好。谢谢。 - Bob Chip

4

我个人偏爱 cluster-master。

https://github.com/isaacs/cluster-master

我喜欢 cluster-master 的原因是它除了增加进程分叉逻辑、允许你管理运行的进程数量以及提供少量日志记录和恢复功能之外,几乎没有做其他事情。我发现过度臃肿的进程管理库往往不稳定,甚至会拖慢运行速度。

如果以下条件适用于您,则此库适合您使用:

  • 您的模块大部分是异步操作的
  • 您没有大量不同类型的事件触发
  • 触发的事件所执行的工作量较小,但您有大量类似的事件触发(例如 Web 服务器)

以上列表的原因,也是为什么 threads-a-gogo 可能适合您的相反的原因。如果您的代码中有一些地方,在事件循环中需要处理大量工作,那么类似 threads-a-gogo 的程序可能非常棒,因为您不需要提前确定要生成多少个工作者,而是在需要时生成它们来完成工作。请注意:如果这些“线程”太多,有可能导致性能下降,启动太多进程会拖慢程序执行速度,但我不想赘述。

总结一下,如果您的模块已经是大部分异步操作,那么您真正需要的是工作者池。这样可以最小化进程不监听事件的停机时间,并最大化您可以使用的处理器数量。除非您有一个非常繁忙的同步调用,否则单个节点事件循环将无法充分利用处理器的单个内核。在这种情况下,您最好使用 cluster-master。我的建议是进行一些基准测试,看看在“最差的情况”下您的程序可以使用多少个内核。假设您的四核机器只能使用单个内核的 33%,那么您可以告诉 cluster-master 启动 12 个工作者。

希望这对您有所帮助!


1
非常基础,非常适合我的当前独特情况,但对于未来的搜索者来说...它已经被放弃了。 - Cory Mawhorter

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接