workerj队列的工作?

我正在开始使用节点的集群API和mongoose为节点写一个工作队列。

我注意到有很多libs已经这样做,但使用redis和fork。 是否有一个很好的理由与使用群集API分叉?

编辑 ,现在我也发现这个: https : //github.com/xk/node-threads-a-gogo – 太多的select!

我宁愿不添加redis,因为我已经使用了mongo。 另外,我的要求是非常宽松的,我想要坚持,但可以没有它的第一个版本。

问题的第二部分:今天最稳定/使用的nodejs工作队列库有哪些?

       

网上收集的解决方案 "workerj队列的工作?"

你有没有尝试https://github.com/rvagg/node-worker-farm ? 它重量轻,不需要单独的服务器。

想跟进这个。 我的解决scheme最终成为了一个自己的群集impl,其中一些群集工作人员是专职的工作人员(即他们只是有代码工作)。

我使用日程安排作业。

Crontypes作业由集群主机计划。 剩下的工作是根据需要在非工作集群中创build的。 (validation电子邮件等)

在此之前,我正在使用kue,但放弃它,因为我的应用程序的其余部分使用mongodb,我不喜欢使用redis只是作业调度。

我个人偏好集群主人。

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

我喜欢集群pipe理员的原因是因为除了添加分支进程的逻辑之外,他们做的很less,并且让您能够pipe理正在运行的进程数量,以及一小部分的日志/恢复引导。 我发现过于庞大的stream程pipe理库往往是不稳定的,有时甚至放缓速度。

如果以下情况属实,这个图书馆对你有好处:

  • 你的模块大部分是asynchronous的
  • 您没有大量不同types的事件触发
  • 发生的事件有less量的工作要做,但是你有很多类似的事件触发(如networking服务器)

以上列表的原因是线程一gogo可能对你有好处,原因相反。 如果你的代码中有几个位置,在你的事件循环中有很多工作要做,像线程一个gogo,专门为这个工作启动一个“线程”是非常棒的,因为你不确定提前有多less工人产卵,而是在需要时产卵。 注意:如果可能产生大量潜在的产卵,如果你开始启动太多的进程,实际上可能会停滞,但是我会离题。

总而言之,如果你的模块已经大部分是asynchronous的,你真正想要的是一个工作池。 为了最大限度地减less进程没有监听事件的停机时间,并最大限度地提高可以使用的处理器的数量。 除非你有一个非常繁忙的同步调用,否则单个节点事件循环将会利用甚至是单个处理器核心的麻烦。 在这种情况下,你最好用集群主机。 我build议做一个基准testing,看看你的程序在“最糟糕的情况下”可以使用多less核心。 假设这是一个核心的33%。 如果你有一个四核心的机器,你告诉集群主人启动你12名工人。

希望这有助于!