MSMQ与SQL Server Service Broker

Question

我有一个由三部分组成的应用程序：

• 面向最终用户和业务合作伙伴的前端网上商店
• 处理这些订单的订单管理系统
• 技术数据库系统，用于处理所订购产品和服务的所有技术细节

今天，这些系统（位于不同的服务器上，由不同的团队开发）使用WCF Web服务进行互操作。

只要所有服务器都启动，此设置就可以正常运行。无论如何，他们不是 - 并非总是如此。

所以我开始考虑使用MSMQ或SQL Server Service Broker来处理这些系统之间的通信 - 至少在网上商店存储订单到订单管理系统或订单管理系统发送时技术数据系统的技术数据。

我希望在整个系统中实现更高的可靠性 - 即使订单管理后端暂时不可用，用户仍然可以下订单并且不会丢失订单。

但最重要的问题是：MSMQ还是Service Broker？这三个系统都是基于Windows和.NET的，并且已经在三个独立的服务器上使用SQL Server。

有没有人有一些可靠的，真实的事实来代表（或反对）这两种技术中的一种？这两套技术的真实体验是什么？利弊。如果你可以从头开始 - 你会选择哪一个？或者你会选择别的东西（什么？）？

Answer 1

我在不同的情况下同样使用过两者。我的偏好非常基本：如果从数据库事件触发消息发送事件，则使用SQL Service Broker;如果事件在代码中，请使用消息队列。该偏好仅仅基于在触发事件的同一平台上设置更容易。