有没有令人信服的理由使用基于AMQP的服务器而不是像beanstalkd或redis这样的东西?

时间:2012-05-02 21:47:03

标签: node.js background scheduled-tasks task-queue

我正在写一个项目,负责处理面向数据服务器的主应用程序之外的任务,这是使用Node.js在javascript中编写的。它需要处理将来安排的任务,并可能处理“现在”的任务。 “现在”只是意味着下一次工作人员可用时,它将按照该任务进行操作,因此这可能无关紧要。工作人员将全部与外部资源交谈,一个示例工作是发送电子邮件。我们是一个小商店,我们没有大量的资源,所以我不想做的一件事是在这个过程中开始混合语言,我已经看到Node可以很容易地为我们这样做,所以这就是我们要去的东西,除非我在开​​始编码之前看到一个令人信服的理由,这很快就会出现。

所有这一切,我无法判断是否有令人信服的理由使用基于AMQP的服务器,如OpenAMQRabbitMQ,而不是Kue或{{3}与节点客户端。所以,我们走了:

是否有令人信服的理由使用基于AMQP的服务器而不是使用像Kood的beanstalkd或redis这样的服务器?如果是的话,哪种基于AMPQ的服务器最适合我布局的架构?如果不是,哪个nosql解决方案(beanstalkd,redis / Kue)最容易设置并且部署速度最快?

1 个答案:

答案 0 :(得分:16)

FWIW,我还没有接受我的答案,我将解释我已经决定了什么以及为什么。如果我没有得到任何看起来比我决定的更好的答案,那么我以后会接受我自己的答案。

我决定选择Kue。它支持多个异步运行的工作程序,对于集群,它可以利用多核系统。它很容易扩展以提供安全性。它得到了Redis的支持,Redis用于这一切,所以我知道我没有使用未经验证的软件支持我的作业流程服务器(这并不是说任何其他的未经证实。)

我选择Kue最令人信服的原因是它提供了一个JSON api,以便客户端应用程序(第一个客户端将成为基于Web的应用程序,但我们也计划制作智能手机应用程序)无需通过面向节点实例的主应用程序即可轻松添加作业,因此在写这篇文章时,我可以完全不受我团队其他成员的影响。我不需要路线,我不需要任何东西,而且它都是为我提供的,所以我不需要写任何东西来支持这一点。这有另一个优点,扩展提供l / p安全性只有授权的客户端才能添加作业,因此我不必直接将我的redis服务器暴露给客户端应用程序。它还有一个内置的Web控制台,API允许客户端非常容易地撤回与给定用户关联的作业列表,因此我们可以在一个漂亮的日历视图中向用户显示他们所有的计划任务。

另一个引人注目的原因是缺乏与让redis和Kue相关的陡峭学习曲线。我以前设置过redis,而且Kue简单而有效。

是的,我是一个懒惰的开发者,但我是一个好懒惰的开发者。

更新:

我有工作和工作,吞吐量惊人。我将任务编组逻辑拆分到它自己的节点实例中,基本上我所要做的就是将我的repo部署到一台新机器并运行node task-server.js以扩展我的worker。我可能需要为Kue添加更多的求职调用,因为我对一些事情的启示,但这很容易。