当我参加了Microsoft的SQL Server 2008演示会时，他们做了一次快速的大屏幕查看我们正在使用的功能。事实证明，在整个演讲厅里，我的公司是唯一使用Service Broker的人。这让我很吃惊，因为我认为会有更多的人使用它。是否有人在SQL Server中使用Service Broker？
我对SB的经验是，它的工作表现很好，但管理起来相当困难，而且很难获得概述。
那么，你有没有考虑过使用Service Broker？如果不是，为什么不呢？你是否选择了MSMQ？ SQL Server 2008中有什么会让你考虑使用Service Broker。
我最近考虑将Service Broker用于某个项目，但是，决定改为使用MSMQ。
我们的架构由许多（集群）服务器组成，每个服务器都需要将信息可靠地写入单个SQL实例。
据我所知，SB只适用于SQL到SQL通信，所以我们需要在每个群集框上使用SQL实例。我们觉得这有点不必要，因此使用MSMQ
说实话，我不能想到一个场景，我会使用SB - 我有兴趣了解更多关于您的场景，看到如果我错过了一些重要的事情。
SB队列存储在SQL数据库中，但任何可以访问数据库的服务器都可以使用它们。所以你只需要一个中央数据库来存储队列。 – 2011-11-09 14:15:36
SQL Query Notificatons（http://msdn.microsoft.com/zh-cn/library/ms130764.aspx）在这里没有提到，但它是Service Broker的大量使用。它提供了一个很好的缓存过期设施。 – EBarr 2012-05-18 21:24:03
我一直在2005年使用SB约两年，每天处理数十万条消息。我认为最大的挑战并不在于架构，而在于了解所涉及的所有细微差别。来自微软的文档很少，只有极少数的实际例子。 Remus Rusanu's blogs在对话重用和激活存储过程调优等方面确实很有帮助。我发现尽可能多地重用对话是非常重要的（并且通过所有与之相关的锁定来处理），并且一次处理多个收到的消息而不是一次处理。
监测SB可能是一种痛苦。你基本上依靠一堆系统视图来告诉你发生了什么。孤独的消息是一种痛苦。只有很多小问题可以，但是，getcha。
除了这些问题，并没有那么多，我认为它确实比我预期的更好。由于SB已集成到数据库中，因此没有单独的消息队列可备份到数据库外部。这一切都是事务一致的。性能很好。这是一个很好的解决方案。
我会再次使用它并继续使用它。
自SQL 2005发布几个月后，我一直在使用SQL Service Broker。我们不停地在这里每天发送数十万条消息。
我们使用它将数据从登台表加载到生产表中，以便加载登台表的服务不必等待数据实际处理，它可以返回并获取更多数据加载。
我们使用它来排队删除文件系统中的文件。 （当行被删除时，文件也需要删除。）
在之前的公司中，我用它来打印贷款文件和发给客户的支票。
我甚至使用Service Broker从OLTP数据库执行ETL到OLAP数据库以进行实时报告。
大多数人（特别是DBA）不喜欢Service Broker，因为它没有任何UI。如果你想使用服务代理或者看看你在做什么，你必须实际编写和运行一些T/SQL。
乔纳斯 - 我可以为丹尼先生担保。他很谦虚，但如果您需要任何Service Broker帮助，则应该与他交谈并阅读他的博客 - http://itknowledgeexchange.techtarget.com/sql-server/ – 2009-02-04 17:00:51
在我现在的公司，我们对SB的使用与其他海报有所不同。我们在SQL2005中主要使用SB作为管理工具。例如，我们使用它来管理对大量不可变数据库中存在的一小组可变表的更新。所有消息都在同一实例上运行的服务之间，消息量非常低。
我对SB的经验是，设置正确可能有点“杂乱”，正如你在你的问题中提到的那样，很难获得SB的状态概述，因为没有一个监测工具。
尽管如此，我们发现它作为一种以可追踪和可靠的方式自动执行大量数据库管理任务的方法非常有价值。
Service Broker可用于需要在分布式体系结构中完成自动化的各种情况。 这种应用程序接收来自各种设备的事件并需要可靠地完成处理。来自设备（检测）或传感器的事件用于处理自动化逻辑。在多个数据库或应用程序之间进行数据交换。
我希望它的实现可以更担保和可靠与SB
我认为，它是如此下使用的是因为文档和工具是很差或者不存在的原因之一。散布的博客文章和不完整的示例不鼓励广泛采用。关于这个问题，有一本书是在四年前写的，据我所知，SQL Server 2012没有提供该产品的增强功能。所有这些让我不愿意使用它，但我知道的唯一真正的替代品是MSMQ或类似的产品。 – 3Sphere 2012-08-26 18:59:48