25

我的团队负责人要求我调查 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

4 回答 4

34

刚刚将我的应用程序从 Service Broker 迁移到 MSMQ，我不得不投票支持使用 MSMQ。有几个因素需要考虑，但其中大部分与您使用数据的方式以及处理的位置有关。

  • 如果在数据库中进行处理？服务经纪人
  • 如果只是数据移动？服务经纪人
  • 处理是在 .NET/COM 代码中完成的吗？MSMQ
  • 您是否需要远程分布式事务（例如，在不同于 SQL 的机器上处理）？MSMQ
  • 您是否需要能够在目的地关闭时发送消息？MSMQ
  • 您想使用 nServiceBus、MassTransit、Rhino-ESB 等吗？MSMQ

无论您选择什么都需要考虑的事项

  • 您如何知道队列的健康状况？这两个选项处理故障转移的方式不同。例如，Service Broker将在某些情况下禁用您的队列，这可能会导致您的应用程序瘫痪。
  • 您将如何进行报告？如果您已经在报表中使用 SQL 表，Service Broker可以轻松适应，因为它只是另一个动态表。如果您已经在使用性能监视器， MSMQ可能更适合。Service Broker确实有很多性能计数器，所以不要让这成为您的唯一因素。
  • 您如何衡量正常运行时间？仅仅是确保您不会丢失交易，还是需要同步响应？我发现MSMQ的分布式特性允许更长的正常运行时间，因为主队列可以离线并且不会丢失任何东西。而使用Service Broker ，您的数据库必须在线，否则您将失败。
  • 您是否已经有使用这些技术之一的经验？两者都有很多实现细节，可以回来咬你。
  • 无论您做出何种选择，切换底层队列技术有多容易？我建议您使用一个通用的 IQueue 接口来编写具体的实现。这样，如果您发现自己做出了错误的选择，以后可以轻松地更改您所做的选择。毕竟，队列只是一个队列，不应将您锁定在特定的实现中。
于 2010-03-23T21:23:15.383 回答
4

我以前使用过 MSMQ，我要添加到您的列表中的唯一项目是版本控制的先决条件检查。我遇到了一个问题，其中一个站点具有 Win 2000 Server 和 MSMQ v.2，而不是 Win 2003 Server 和 MSMQ v3。我所有的 .NET 代码都针对 v.3 并且它们不兼容......或者至少不容易兼容。

如果您走 MSMQ 路线，请考虑一下。

于 2008-10-27T18:55:33.247 回答
3

MSMQ 中的消息大小限制已经停止了我在那个方向上的挖掘。我正在为该项目学习 Service Broker。

于 2009-11-23T03:12:27.987 回答
1

您是否需要能够在目的地关闭时发送消息？MSMQ

我不明白为什么？SSB 可以毫无问题地将消息发送到断开连接的目的地。所有这些消息都进入传输队列，并在目的地保持可达时被传递。

于 2010-08-19T08:07:06.803 回答