我一直在进行 SQL Server Service Broker 范围的研发，以取代当前的消息传递解决方案 MSMQ。我想了解 SQL Server Service Broker 与 MSMQ 相比在以下标准方面的缺点。
- 开发
- 问题排查
- 性能(假设我们每天需要处理 100,000 条消息，平均大小约为 25 KB)
- 可扩展性
最佳答案
我在当前的项目中使用了 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 。 (如果您确实使用 Service Broker，那么您不妨在开始之前阅读 Remus 就该主题撰写的所有内容，因为您最终会读完它!)
可扩展性
如果需要，您当然可以使用多个服务器来扩展，尽管我们没有必要这样做，而且从您提到的负载大小来看，我认为您也不需要这样做。
我认为我没有真正设法回答您的问题，因为我没有充分强调 Service Broker 队列的缺点。我想说，其内部运作的难以理解的本质是最让我恼火的事情——当它工作时，它工作得很好，但当它停止工作时，很难弄清楚为什么。此外，如果队列中有大量消息，则使用 ALTER QUEUE 需要很长时间才能完成。
不知道如何使用 MSMQ 也会导致公平比较这两种技术变得不同。
1 在要点中重新创建为 original url现在已“禁用”，并且该页面不在互联网文件中。最终找到了一份here
关于sql-server - SQL Server Service Broker 的缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21570337/