处理NodeJS应用程序中的后台进程有什么好处？
Scenario ：在用户向应用程序发布内容之后，我想要处理数据，从外部资源请求其他数据等 . 所有这些都非常耗时，所以我想要它来自req / res循环 . 理想的情况是拥有一个可以快速转储作业的作业队列，守护程序或任务运行器将始终使用最旧的作业并对其进行处理 .
在RoR中，我会用延迟工作这样做 . 这个API的Node等价物是什么？
如果你想要一些轻量级的东西，它在与服务器相同的进程中运行，我强烈推荐Bull . 它有一个简单的API，允许对队列进行细粒度控制 .
如果您正在寻找作为独立工作进程运行的东西，也许请查看Kue . 它可以作为RESTful API服务器运行，甚至还有几个为它编写的前端应用程序 .
如果您使用了Resque，那么有一个名为Node-resque的节点实现
Bull，Kue和Node-resque都支持Redis，这在Node.js工作队列中无处不在 . 所有3个人都可以做你想要的特定功能和你的API偏好 .
后台作业与您的Web服务工作没有直接关系，因此它们不应该在同一个过程中 . 在向上扩展时，后台作业的内存使用量将影响Web服务性能 . 但是如果你愿意的话，你可以把它们放在同一个代码库中，无论什么更有意义 .
两个进程之间的消息传递的一个很好的选择是redis，如果每次都丢弃一条消息然后就可以了 . 如果你想要"no message left behind"，你需要一个更重量级的经纪人，如Rabbit . 您的Web服务进程可以发布，后台作业进程可以订阅 .
这两个进程没有必要共同托管，它们可以位于不同的VM，Docker容器，无论您使用什么 . 这使您可以毫不费力地扩展 .
如果您使用的是MongoDB，我建议使用Agenda . 这样，单独的Redis实例不会运行，并且调度，排队和Web UI等功能都存在 . Agenda UI是可选的，当然可以单独运行 .
还建议在应用程序逻辑和排队/调度系统之间 Build 松散耦合的抽象，以便在需要时可以换出整个后台处理系统 . 换句话说，保持尽可能多的应用程序/处理逻辑远离您的Agenda作业定义，以保持它们的轻量级 .
我想建议使用Redis来安排工作 . 它有许多不同的数据结构，您可以随时选择一个更适合您的用例 .
你提到过RoR和DJ，所以我假设你对sidekiq很熟悉 . 如果你愿意，可以使用node-sidekiq作为作业调度，但是它的次优imo，因为它的主要目的是将nodejs与RoR集成 .
对于工作人员守护我建议使用PM2 . 这对你来说太过分了 .
我试过bee-queue＆bull并最终选择了牛 . 我首先选择了bee-queue b / c这很简单，他们的例子很容易理解，而公牛's examples are bit complicated. bee'的wiki Bee Queue's Origin也引起了我的共鸣 . 但蜜蜂的问题是<1>他们的问题解决时间很慢，他们的最新更新是10个月前 . <2>我找不到暂停/取消工作的简单方法 .
另一方面，Bull经常更新他们的代码，回应问题 . Node.js job queue evaluation说公牛的弱点是"slow issues resolution time"，但我的经历恰恰相反！
但无论如何他们的api是相似的，所以很容易从一个切换到另一个 .
我建议使用适当的Node.js框架来构建你的应用程序 .
我认为最强大且易于使用的是Sails.js .
这是一个MVC框架，所以如果你习惯在ROR中开发，你会发现它非常容易！
如果您使用它，它已经提供了一个功能强大的（用javascript术语）作业管理器 .
new sails.cronJobs('0 01 01 * * 0', function () { sails.log.warn("START ListJob"); }, null, true, "Europe/Dublin");
如果您需要更多信息，请随时与我联系！
6 回答
如果你想要一些轻量级的东西，它在与服务器相同的进程中运行，我强烈推荐Bull . 它有一个简单的API，允许对队列进行细粒度控制 .
如果您正在寻找作为独立工作进程运行的东西，也许请查看Kue . 它可以作为RESTful API服务器运行，甚至还有几个为它编写的前端应用程序 .
如果您使用了Resque，那么有一个名为Node-resque的节点实现
Bull，Kue和Node-resque都支持Redis，这在Node.js工作队列中无处不在 . 所有3个人都可以做你想要的特定功能和你的API偏好 .
后台作业与您的Web服务工作没有直接关系，因此它们不应该在同一个过程中 . 在向上扩展时，后台作业的内存使用量将影响Web服务性能 . 但是如果你愿意的话，你可以把它们放在同一个代码库中，无论什么更有意义 .
两个进程之间的消息传递的一个很好的选择是redis，如果每次都丢弃一条消息然后就可以了 . 如果你想要"no message left behind"，你需要一个更重量级的经纪人，如Rabbit . 您的Web服务进程可以发布，后台作业进程可以订阅 .
这两个进程没有必要共同托管，它们可以位于不同的VM，Docker容器，无论您使用什么 . 这使您可以毫不费力地扩展 .
如果您使用的是MongoDB，我建议使用Agenda . 这样，单独的Redis实例不会运行，并且调度，排队和Web UI等功能都存在 . Agenda UI是可选的，当然可以单独运行 .
还建议在应用程序逻辑和排队/调度系统之间 Build 松散耦合的抽象，以便在需要时可以换出整个后台处理系统 . 换句话说，保持尽可能多的应用程序/处理逻辑远离您的Agenda作业定义，以保持它们的轻量级 .
我想建议使用Redis来安排工作 . 它有许多不同的数据结构，您可以随时选择一个更适合您的用例 .
你提到过RoR和DJ，所以我假设你对sidekiq很熟悉 . 如果你愿意，可以使用node-sidekiq作为作业调度，但是它的次优imo，因为它的主要目的是将nodejs与RoR集成 .
对于工作人员守护我建议使用PM2 . 这对你来说太过分了 .
我试过bee-queue＆bull并最终选择了牛 . 我首先选择了bee-queue b / c这很简单，他们的例子很容易理解，而公牛's examples are bit complicated. bee'的wiki Bee Queue's Origin也引起了我的共鸣 . 但蜜蜂的问题是<1>他们的问题解决时间很慢，他们的最新更新是10个月前 . <2>我找不到暂停/取消工作的简单方法 .
另一方面，Bull经常更新他们的代码，回应问题 . Node.js job queue evaluation说公牛的弱点是"slow issues resolution time"，但我的经历恰恰相反！
但无论如何他们的api是相似的，所以很容易从一个切换到另一个 .
我建议使用适当的Node.js框架来构建你的应用程序 .
我认为最强大且易于使用的是Sails.js .
这是一个MVC框架，所以如果你习惯在ROR中开发，你会发现它非常容易！
如果您使用它，它已经提供了一个功能强大的（用javascript术语）作业管理器 .
如果您需要更多信息，请随时与我联系！