我正在为一个项目写一篇文章，该项目负责处理面向数据服务器的主应用程序之外的任务，该数据服务器是使用 Node.js 用 javascript 编写的。它需要处理未来安排的任务，并可能处理“现在”的任务。“现在”只是意味着下次有工作人员可用时，它将执行该任务，因此该位可能无关紧要。工作人员都将与外部资源交谈，一个示例工作是发送电子邮件。我们是一家小商店，我们没有大量资源，所以我不想做的一件事就是在这个过程中开始混合语言，我已经看到 Node 可以很容易地为我们做到这一点，所以这就是我们
尽管如此，我不知道是否有令人信服的理由使用基于 AMQP 的服务器，比如OpenAMQ或RabbitMQ，而不是像Kue或Beanstalkd这样的节点客户端。所以，我们开始：
是否有令人信服的理由使用基于 AMQP 的服务器而不是带有 Kue 的 beanstalkd 或 redis？如果是，哪款基于 AMPQ 的服务器最适合我布置的架构？如果不是，哪种 nosql 解决方案（beanstalkd、redis/Kue）最容易设置和部署最快？
FWIW，我还没有接受我的答案，我将解释我的决定以及原因。如果我没有得到任何似乎比我决定的更好的答案，我稍后会接受我自己的答案。
我选择了酷。它支持多个异步运行的worker，并且通过集群它可以利用多核系统。它很容易扩展以提供安全性。它以 Redis 为后盾，完全用于这个确切的事情，所以我知道我不会用未经证实的软件支持我的工作流程服务器（这并不是说其他任何软件都未经证实。）
我选择 Kue 的最令人信服的原因是它提供了一个 JSON api，以便客户端应用程序（第一个客户端将是一个基于 Web 的应用程序，但我们也计划制作智能手机应用程序）可以轻松添加工作而无需通过面向节点实例的主应用程序，所以在我写这篇文章时，我可以完全避开我团队的其他成员。我不需要路线，我不需要任何东西，而且都是为我提供的，所以我不需要写任何东西来支持这一点。这还有另一个优点，提供 l/p 安全性的扩展，只有授权的客户端才能添加作业，所以我不必将我的 redis 服务器直接暴露给客户端应用程序。它还有一个内置的 Web 控制台，API 允许客户端很容易地拉回与给定用户关联的作业列表，
另一个令人信服的原因是缺乏与让 redis 和 Kue 为我服务相关的陡峭学习曲线。我之前设置过redis，Kue简单有效。
是的，我是一个懒惰的开发者，但我是那种懒惰的开发者。
更新：
我让它工作和做工作，吞吐量是惊人的。我将任务编组逻辑拆分到它自己的节点实例中，基本上我所要做的就是将我的 repo 部署到一台新机器上并运行 node task-server.js 来扩展我的工人。我可能需要添加更多对 Kue 的求职电话，因为我如何实现了一些事情，但这很容易。