是否有人在使用SQL Server中的Service Broker？

Question

当我在微软参加SQL Server2008的演示时，他们做了一个快速的盖洛普，看看我们在使用什么功能。事实证明，在整个报告厅中，我的公司是唯一使用Service Broker的公司。这让我很惊讶，因为我以为会有更多的人使用它。

我对SB的经验是，它很好地完成了它的工作，但管理起来相当困难，很难获得概述。

那么，您是否考虑过使用Service Broker？若否，原因为何？你用MSMQ代替了吗？SQL Server 2008中有没有什么东西会让您考虑使用Service Broker。

Answer 1

从SQL 2005发布后的几个月开始，我就一直在使用SQL Service Broker。我们在这里不间断地使用它，每天通过它发送数十万条消息。

我们使用它将数据从临时表加载到生产表，以便加载临时表的服务不必等待数据实际处理，它可以返回并加载更多数据。

我们使用它来对从文件系统中删除文件进行排队。(删除行时，也需要删除文件。)

在以前的公司，我用它来打印贷款文件和发送给客户的支票。

我甚至使用Service Broker执行从OLTP数据库到OLAP数据库的ETL，以便进行实时报告。

大多数人(尤其是DBA)不喜欢Service Broker，因为它没有任何UI。如果您想使用service broker或查看它在做什么，您必须实际编写和运行一些T/SQL。

Answer 2

我在2005年已经使用SB大约两年了，有一个实现每天处理几十万条消息。我想说，最大的挑战不是在架构上，而是理解所有涉及的细微差别。微软的文档很差，几乎没有实际的例子。Remus Rusanu's blogs在对话框重用和激活存储过程调优等方面确实很有帮助。我发现尽可能多地重用对话框(并完成与此相关的所有相关锁定)以及将多个接收到的消息作为一个集合来处理而不是一次处理一个消息，这一点非常重要。

监视某人可能是件痛苦的事。您基本上依赖于一堆系统视图来告诉您发生了什么。孤立的消息是一种痛苦。只是有很多小陷阱可以，好吧，得到你。

抛开问题不谈，我认为它真的比我预期的要好。由于SB已集成到数据库中，因此没有单独的消息队列可以备份到数据库之外。它们在事务上都是一致的。性能很好。这是一个很好的解决方案。

我会再次使用它，并将继续使用它。

Answer 3

在我目前的公司，我们对SB的用法与其他海报的用法有些不同。我们在SQL2005中主要使用SB作为管理工具。例如，我们使用它来管理对一小部分可变表的更新，这些表存在于大量其他不可变的数据库中。所有消息都在同一实例上运行的服务之间，消息量非常小。

我对SB的经验是，正确设置可能有些“繁琐”，而且，正如您在问题中提到的，很难获得SB状态的概述，因为没有一个单一的监控工具。

然而，我们发现它作为一种以可跟踪和可靠的方式自动化许多数据库管理任务的方法具有巨大的价值。