我一直在为SQL Server Service Broker的范围做r＆amp; d来替换当前的消息传递解决方案MSMQ。我想知道SQL Server Service Broker的缺点，与MSMQ相比，它符合以下标准。
答案 0 :(得分：33)
我在我当前的项目中使用过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 在gist中重新创建，因为original url现在已“禁用”且页面不在互联网档案中。最终找到了副本here