Node.js中的后台进程

Question

处理NodeJS应用程序中的后台进程有什么好处？

场景:在用户向应用程序发布内容后,我想要处理数据,从外部资源请求其他数据等.所有这些都非常耗时,所以我想要它来自req/res循环.理想的情况是拥有一个可以快速转储作业的作业队列,守护程序或任务运行器将始终使用最旧的作业并对其进行处理.

在RoR中,我会用延迟工作这样做.这个API的Node等价物是什么？

Answer 1

如果你想要一些轻量级的东西,它在与服务器相同的过程中运行,我强烈推荐Bull.它有一个简单的API,允许对队列进行细粒度控制.

如果您正在寻找作为独立工作流程运行的东西,也许请查看Kue.它可以作为RESTful API服务器运行,甚至还有几个为它编写的前端应用程序.

如果您熟悉Ruby的Resque,那么有一个名为Node-resque的节点实现

Bull,Kue和Node-resque都得到Redis的支持,Redis在Node.js工作队列中无处不在.所有3个都能够完成RoR的DelayedJob所做的事情,这是你想要的具体功能和你的API偏好.

Answer 2

后台作业与您的Web服务工作没有直接关系,因此它们不应该在同一个过程中.在向上扩展时,后台作业的内存使用量将影响Web服务性能.但是如果你愿意的话,你可以把它们放在同一个代码库中,无论什么更有意义.

两个进程之间的消息传递的一个很好的选择是redis,如果每次都丢弃一条消息然后就可以了.如果你想"不留下任何消息",你将需要一个像Rabbit这样更重量级的经纪人.您的Web服务进程可以发布,后台作业进程可以订阅.

这两个进程没有必要共同托管,它们可以位于不同的VM,Docker容器,无论您使用什么.这使您可以毫不费力地扩展.

Answer 3

如果您使用的是MongoDB,我建议使用Agenda.这样,单独的Redis实例不会运行,并且调度,排队和Web UI等功能都存在. Agenda UI是可选的,当然可以单独运行.

还建议在应用程序逻辑和排队/调度系统之间建立松散耦合的抽象,以便在需要时可以换出整个后台处理系统.换句话说,保持尽可能多的应用程序/处理逻辑远离您的Agenda作业定义,以保持它们的轻量级.

Answer 4

我建议使用Redis来调度作业。它有很多不同的数据结构，您始终可以选择一种更适合您的用例的数据结构。

您提到了 RoR 和 DJ，所以我假设您熟悉 sidekiq。如果你愿意的话，你可以使用node-sidekiq来进行作业调度，但在我看来，它并不是最理想的，因为它的主要目的是将nodejs与RoR集成。

对于工作人员守护进程，我建议使用PM2。它被广泛使用并得到积极维护。它解决了很多问题（例如部署、监控、集群），所以请确保它不会对您造成太大的杀伤力。