解決方案/架構：隊列還是其他？

Question

我有用Node.js編寫的服務和用Ruby編寫的工作者的多個前端。現在的問題是如何讓那些溝通？我需要維護動態的工作人員池來處理負載（當負載上升時產生更多的工作人員），並且消息相當大〜2-3M，因爲我正在通過Node.js前端向用戶上傳的工作人員發送圖像。因爲我想要很好的縮放，所以我想到了一些排隊解決方案，但是我沒有找到任何現有解決方案（或誤解指南），它們將提供：

1. 回退機制。我迄今發現的解決方案有單一的故障點 - 消息代理，並且沒有辦法提供回退。
2. 序列化。所以當代理失敗時，任務不會丟失。
3. 傳遞大消息的能力。
4. Ruby和Node.js的簡單API
5. 一些用於跟蹤隊列大小的API，以便我可以重新排列工作池。
6. 重量輕。

也許我的做法是錯誤的？也許我不應該使用隊列，但有其他方式？或者有一些符合上述要求的排隊解決方案？

Answer 1

有趣的文章，我把ZeroMQ隊列的解決方案。非常快速，健壯和輕量級的實現。不得不寫自己的經紀人，但那是唯一的缺點這個解決方案。

Answer 2

Redis的發佈/訂閱應該做的伎倆

http://redis.io/topics/pubsub

Answer 3

您需要一個隊列規模毫無疑問，你可以監視此隊列中產卵「打工皇帝」。

Apache ActiveMQ非常強大並且支持REST協議。 Ruby客戶端也可以訪問隊列。在一天結束的RESTful queue using Apache ActiveMQ