我的团队负责人要求我调查 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 版本，因此我们必须升级所有客户端代码。谢谢你的帮助!
刚刚将我的应用程序从 Service Broker 迁移到 MSMQ，我不得不投票支持使用 MSMQ。有几个因素需要考虑，但其中大部分与您使用数据的方式以及处理的位置有关。
如果在数据库中进行处理？ 服务经纪人 如果只是数据移动？ 服务经纪人 处理是在 .NET/COM 代码中完成的吗？ MSMQ 您是否需要远程分布式事务(例如，在不同于 SQL 的机器上处理)？ MSMQ 您是否需要能够在目的地关闭时发送消息？ MSMQ 您想使用 nServiceBus、MassTransit、Rhino-ESB 等吗？ MSMQ 无论您选择什么都需要考虑的事项
您如何知道队列的健康状况？这两个选项处理故障转移的方式不同。例如 服务经纪人 将在某些情况下禁用您的队列，这可能会导致您的应用程序崩溃。 您将如何进行报告？如果您已经在报告中使用 SQL 表，服务经纪人 可以很容易地适应，因为它只是另一个动态表。如果您已经在使用性能监视器 MSMQ 可能更适合。 服务经纪人 确实有很多性能计数器，所以不要让它成为你唯一的因素。 您如何衡量正常运行时间？仅仅是确保您不会丢失交易，还是需要同步响应？我发现 的分布式特性MSMQ 允许更长的正常运行时间，因为主队列可以离线并且不会丢失任何东西。而 服务经纪人 您的数据库必须在线，否则您将失败。 您是否已经有使用这些技术之一的经验？两者都有很多实现细节，可以回来咬你。 无论您做出何种选择，切换底层队列技术有多容易？我建议您使用一个通用的 IQueue 接口(interface)来编写具体的实现。这样，如果您发现自己做出了错误的选择，以后可以轻松地更改您所做的选择。毕竟，队列只是一个队列，不应将您锁定在特定的实现中。