我的团队负责人已经要求我调查MSMQ作为我们产品新版本的选项。我们在当前版本中使用SQL Service Broker。我已经做了相当多的实验和谷歌搜索，找到哪个产品更符合我的需求，但我想我会问我最熟悉的网站来编程答案。
一些细节：
- 我们的客户端是.NET 1.1和2.0代码;这是消息将从哪里发送的。
- SQL Server 2005实例中的目标。所有消息最终都是数据库更新或插入。
- 我们将发送几个必须视为交易的更新。
- 我们必须拥有完美的消息可恢复性;没有消息可以丢失。
- 我们必须是异步的，即使目标SQL服务器关闭也能接受消息。
- 开发我们自己的排队解决方案不是一种选择;我们是一个小团队。
到目前为止我发现的事情：
- MSMQ和SQL Service Broker都可以完成这项工作。
- 服务代理似乎对交易消息更快。
- Service Broker需要在某处运行SQL服务器，而MSMQ需要在任何地方运行任何已配置的Windows机器。
- MSMQ似乎更好/更快/更容易在群集中设置/运行。
我错过了什么吗？这里有明显的赢家吗？任何想法，经验或链接都会受到重视。谢谢！
编辑：我们最终坚持使用服务代理，因为我们的一些客户端代码中使用了自定义数据库框架（我们更好地处理事务）。该代码捕获了事务的SQL，但没有。客户端代码也是.NET的1.1版本，因此我们必须升级所有客户端代码。谢谢你的帮助！
4 个答案:
答案 0 :(得分：34)
刚刚将我的应用程序从Service Broker迁移到MSMQ，我将不得不投票使用MSMQ。有几个因素需要考虑，但其中大部分都与您使用数据的方式和处理方式有关。
- 如果在数据库中进行处理？ Service Broker
- 如果只是数据移动？ Service Broker
- 是否在.NET / COM代码中完成处理？的 MSMQ
- 您是否需要远程分布式事务（例如，在不同于SQL的框上处理）？的 MSMQ
- 您是否需要在目的地关闭时发送消息？的 MSMQ
- 您想使用nServiceBus，MassTransit，Rhino-ESB等吗？的 MSMQ
无论你选择什么都要考虑的事情
- 您如何知道队列的健康状况？这两个选项都以不同方式处理故例如， Service Broker 将在某些可能导致您的应用程序失效的情况下禁用您的队列。
- 您将如何执行报告？如果您已在报告中使用SQL表，那么 Service Broker 可以很容易地适应，因为它只是另一个动态表。如果您已经在使用性能监视器 MSMQ 可能更适合。 Service Broker 确实有很多性能指标，所以不要让这成为唯一的因素。
- 你如何衡量正常运行时间？它只是确保您不会丢失交易，还是需要同步响应？我发现 MSMQ 的分布式特性允许更长的正常运行时间，因为主队列可以脱机而不会丢失任何东西。而使用 Service Broker ，您的数据库必须在线，否则您将失败。
- 您是否已经拥有其中一种技术的经验？两者都有很多实现细节，可以回来咬你。
- 无论您做出何种选择，切换底层排队技术有多容易？我建议您使用一个通用的IQueue接口来编写具体的实现。这样，如果您发现错误的选择，您可以在以后轻松更改您所做的选择。毕竟，队列只是一个队列，不应该将您锁定在特定的实现中。
答案 1 :(得分：4)
之前我使用过MSMQ，我添加到列表中的唯一项目是版本控制的先决条件检查。我遇到了一个问题，其中一个站点有Win 2000 Server，因此有MSMQ v.2，而不是Win 2003 Server和MSMQ v3。我的所有.NET代码都针对v.3而且它们不兼容......或者至少不容易这样。
如果您选择MSMQ路线，请考虑一下。
答案 2 :(得分：3)
MSMQ中的邮件大小限制已经停止了我在这方面的挖掘。我正在为该项目学习Service Broker。
答案 3 :(得分：1)
目的地关闭时，您是否需要能够发送消息？ MSMQ
我不明白为什么？ SSB可以毫无问题地将消息发送到断开连接的目标。所有这些消息都将传输到传输队列，并在目标保持可达时传递。