解决方案/架构：队列还是其他？

Question

我的服务有多个用 Node.js 编写的前端和用 Ruby 编写的工作线程。现在的问题是如何让它们进行通信？我需要维护动态工作人员池来处理负载（当负载上升时产生更多工作人员）并且消息相当大~2-3M，因为我将图像发送给用户通过 Node.js 前端上传的工作人员。因为我想要很好的扩展，所以我考虑了一些排队解决方案，但我没有找到任何现有的解决方案（或误解的指南）来提供：

1. 后备机制。到目前为止，我发现的解决方案只有一个故障点 - 消息代理，并且没有办法提供后备。
2. 序列化。因此，当代理失败时，任务不会丢失。
3. 能够传递重要信息。
4. 适用于 Ruby 和 Node.js 的简单 API
5. 一些 API 可以跟踪队列大小，以便我可以重新安排工作池。
6. 最好是轻量的。

也许我的做法是错误的？也许我不应该使用队列，而应该使用其他方式？或者有一些符合上述要求的排队解决方案吗？

Answer 1

毫无疑问，您需要一个队列来扩展，并且您可以监视该队列以产生“工人”。

Apache ActiveMQ 非常强大并且支持 REST 协议。 Ruby 客户端也可用于访问队列。

关于使用 Apache ActiveMQ 的 RESTful 队列的有趣文章

Answer 2

最终我采用了

ZeroMQ队列解决方案。非常快速、强大且轻量级的实施。必须编写自己的代理，但这是该解决方案的唯一缺点。

Answer 3

redis 发布/订阅应该可以解决问题

http://redis.io/topics/pubsub