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


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

所有这一切,我不知道是否有令人信服的理由使用基于AMQP的服务器,如 OpenAMQ 要么 的RabbitMQ 在类似的东西 苦厄 要么 Beanstalkd 与节点客户端。那么,我们走了:

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


11254
2018-05-02 21:47


起源



答案:


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

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

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

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

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

更新:

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


16
2018-05-03 00:19



顺便说一下,当我问问题时,我基本上做出了这个决定,但是有人告诉我要查看基于AMQP的解决方案,而且我基本上处于决策的最后期限,所以我希望得到一些反馈。在研究了最后几个小时之后,我决定找不到使用Kue的理由。 - Nathan C. Tresch
我认为,使用Kue与标准消息队列协议(如AMQP)之间的权衡之一就是其他语言中没有客户端。 - az_
你还在使用Kue吗? - bob_cobb
@bob_cobb我从那个位置开始了。当我在那里时,它为我们很好地工作。 - Nathan C. Tresch
@ NathanC.Tresch - 感谢选择Kue的好解释。你有没有机会与Kue比较 github.com/mpneuried/rsmq-worker ? - Samba


答案:


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

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

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

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

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

更新:

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


16
2018-05-03 00:19



顺便说一下,当我问问题时,我基本上做出了这个决定,但是有人告诉我要查看基于AMQP的解决方案,而且我基本上处于决策的最后期限,所以我希望得到一些反馈。在研究了最后几个小时之后,我决定找不到使用Kue的理由。 - Nathan C. Tresch
我认为,使用Kue与标准消息队列协议(如AMQP)之间的权衡之一就是其他语言中没有客户端。 - az_
你还在使用Kue吗? - bob_cobb
@bob_cobb我从那个位置开始了。当我在那里时,它为我们很好地工作。 - Nathan C. Tresch
@ NathanC.Tresch - 感谢选择Kue的好解释。你有没有机会与Kue比较 github.com/mpneuried/rsmq-worker ? - Samba