SQL Server Service Broker 的缺点 [关闭]

Posted 2023-03-10

【中文标题】SQL Server Service Broker 的缺点 [关闭]

【英文标题】：Disadvantages of SQL Server Service Broker [closed]

【发布时间】：2014-03-01 11:25:27

【问题描述】：

我一直在为 SQL Server Service Broker 的范围做研发，以取代当前的消息传递解决方案 MSMQ。我想了解 SQL Server Service Broker 与 MSMQ 相比的劣势，以符合以下标准。

发展 疑难解答 性能（假设我们每天需要处理 100,000 条消息，平均大小约为 25 KB） 可扩展性

【参考方案1】：

我在当前项目中使用过 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 ¹ 这样的对话框池来创建 Service Broker 对话框 can be an expensive operation。

您还需要使用the Error Handling procedures detailed by Remus Rusanu。 （如果您确实使用服务代理，那么您不妨在开始之前阅读 Remus 所写的所有内容，因为您最终会读完它！）

可扩展性

如果需要，您当然可以使用多台服务器进行扩展，尽管我们不必这样做，而且从您提到的负载大小来看，我认为您也不需要。

我认为我没有真正回答您的问题，因为我没有充分强调 Service Broker 队列的缺点。我会说它内部运作的难以理解的本质是最让我烦恼的事情 - 当它工作时，它工作得很好，但当它停止工作时，很难弄清楚为什么。此外，如果队列中有很多消息，使用ALTER QUEUE 需要很长时间才能完成。

不知道您是如何使用 MSMQ 也使得公平比较这两种技术变得不同。

¹ 由于original url 现在已“禁用”并且该页面不在互联网档案中，因此重新创建了一个要点。终于找到了一份here

【讨论】：

我不认为每秒 27 条消息是好的性能。

在这种情况下，27 条消息表示每秒向 SQL 表写入 27,000（大）行，因为每条消息中都有 1000 个数据项。可能可以获得更高的插入性能，但我们已经达到了目标，还有余地，所以似乎没有必要

100 000 msgs/hour 和 100000/60/60=28msgs/sec 不一样吗？

我并不反对你的数学，我只是不明白你的意思。

我的意思是 100k/小时并不是出色的性能。我的客户经常使用 SSB（每秒 5-100 条消息），并且在队列增长时经常遇到麻烦。那时整个服务代理往往会变慢。