我一直在为 SQL Server Service Broker 的范围做研发，以取代当前的消息传递解决方案 MSMQ。我想了解 SQL Server Service Broker 与 MSMQ 相比的劣势，以符合以下标准。
【问题讨论】：
标签： sql-server msmq message-queue service-broker
我在当前项目中使用过 Service Broker，之前使用过 MSMQ（由MassTransit 代理）并取得了巨大成功。我最初对使用 Service Broker 持怀疑态度，但我不得不承认它的表现非常好。
如果您使用的是发布/订阅模型，那么我每次都会使用消息队列（尽管如果项目允许，我会使用 RabbitMQ 而不是 MSMQ）但是当您只想浏览一堆数据并将其持久化时对于 Sql Server，Service Broker 是一个很好的解决方案：它如此“接近金属”这一事实是一个很大的优势。
发展
Service Broker 需要大量样板文件，这很痛苦，但除非您计划拥有许多不同的队列，否则它是易于管理的。 Visual Studio 中的 Sql Server 项目消除了很多部署的痛苦。
疑难解答
Service Broker 是一个黑匣子 - 消息进入，它们通常会出来，但如果它们不这样做，那么故障排除可能会出现问题，你所能做的就是 query the system views - 有时你根本找不到出了什么问题。这很烦人，但 MSMQ 也有同样的问题..
性能
Service Broker 性能非常出色。我们每天处理超过 100,000 条消息，在 SLA 负载下每小时超过 30,000 条，而且我们的消息量很大。我估计我们在高负载测试期间每小时处理近 100,000 条消息。
为了获得最佳性能，我建议您使用像 this one 1 这样的对话框池来创建 Service Broker 对话框 can be an expensive operation。
您还需要使用the Error Handling procedures detailed by Remus Rusanu。 （如果您确实使用服务代理，那么您不妨在开始之前阅读 Remus 所写的所有内容，因为您最终会读完它！）
可扩展性
如果需要，您当然可以使用多台服务器进行扩展，尽管我们不必这样做，而且从您提到的负载大小来看，我认为您也不需要。
我认为我没有真正回答您的问题，因为我没有充分强调 Service Broker 队列的缺点。我会说它内部运作的难以理解的本质是最让我烦恼的事情 - 当它工作时，它工作得很好，但当它停止工作时，很难弄清楚为什么。此外，如果队列中有很多消息，使用ALTER QUEUE 需要很长时间才能完成。
不知道您是如何使用 MSMQ 也使得公平比较这两种技术变得不同。
1 由于original url 现在已“禁用”并且该页面不在互联网档案中，因此重新创建了一个要点。终于找到了一份here
【讨论】：