用于互联网连接的分布式C＃客户端的消息队列解决方案

Question

我正处于调查C＃消息排队解决方案的初始阶段，我很欣赏任何经验，经验教训，战争故事等。我还有一些关于MSMQ适合我们配置的具体问题。

简而言之，我们有一个分布式架构：各种服务器端事件生成由我们部署的客户端检索的工作项。这些客户端连接到服务器，检索工作并处理它，然后返回“等待工作”。

关于这些客户的一些相关细节：

1. 我们今天安装了数百个客户端，需要在未来18个月内为成千上万的增长做好准备。
2. 客户端从不向服务器提交任务 - 它们只是“拉动”。
3. 对客户的有效负载为＆lt; = 1K。
4. 我们不需要重量级认证，也不需要加密流量（虽然这是一个很好的奖励）
5. 我们的客户在各种MS操作系统上运行，＆gt; = WinXP-SP1。有些是Windows活动目录，Windows域或临时工作组的一部分。
6. 主要是客户闲置。我们希望有效地“等待工作”，然后尽快回复工作（即，我们希望客户在排队后尽快收到工作项目）
7. 偶尔，我们的客户会从互联网上消失一段时间：他们的机器被关闭了一天，或者一夜之间等等。我们希望工作项目在他们重新上线时到达。换句话说，我们确实需要消息可靠性。
8. 我们控制所有客户端和服务器代码，但不控制客户端环境（尽管我们的安装程序会安装必备软件，如.NET 3.5，如果它已经不存在）

所以，鉴于上述情况，MSMQ会“自然地”为我们工作吗？我没有找到一个明确的答案，当MSMQ不在域/活动目录中以及通过互联网连接时如何（或者如果）处理客户端监听消息。到目前为止，我对MSMQ的阅读感觉非常“以企业为中心” - 我们的非企业要求是否会成为MSMQ的问题？

您过去在类似设置中使用过哪些其他解决方案？

当然，我应该问其他什么问题？ ; - ）

谢谢！

Answer 1

RabbitMQ听起来像是你的解决方案。

RabbitMQ

RabbitMQ .NET/WCF Library

Answer 2

如果您正在查看Internet上的中央服务器，其中队列中包含等待远程客户端读取消息的消息，那么MSMQ不适合您（很难说我这么做）。 MSMQ无法使用HTTP通过Internet提取消息。 你必须打开端口135并使用RPC协议，这在互联网上不一定是个好主意。

干杯 John Breakwell