当我参加Microsoft的SQL Server 2008演示时，他们快速了解了我们正在使用的功能。事实证明，在整个演讲厅，我的公司是唯一使用Service Broker的公司。这让我感到很惊讶，因为我认为会有更多的人使用它。
我对SB的经验是，它的工作做得很好，但管理非常困难，很难得到概述。
那么，您是否考虑过使用Service Broker？如果没有，为什么不呢？你有没有去过MSMQ？ SQL Server 2008中是否有任何可以让您考虑使用Service Broker的内容。
答案 0 :(得分：24)
自SQL 2005发布几个月后，我一直在使用SQL Service Broker。我们在这里不停地使用它，每天通过它发送数十万条消息。
我们使用它将数据从登台表加载到生产表，以便加载登台表的服务不必等待数据实际处理，它可以返回并获取更多数据加载。
我们使用它来排队从文件系统中删除文件。 （删除行时，也需要删除文件。）
在以前的公司，我用它来打印贷款文件和发给客户的支票。
我甚至使用Service Broker从OLTP数据库到OLAP数据库进行ETL实时报告。
大多数人（特别是DBA）不喜欢Service Broker，因为它没有任何UI。如果你想使用服务代理或者看看你在做什么，你必须实际编写并运行一些T / SQL。
答案 1 :(得分：12)
我在2005年使用SB大约两年了，其中一个实现每天处理数十万条消息。我要说的是，最大的挑战不是在建筑方面，而是要了解所涉及的所有细微差别。微软的文档很少，但很少有实际例子。 Remus Rusanu's blogs在执行对话重用和激活存储过程调优等方面确实很有帮助。我发现尽可能多地重用对话框（以及处理所涉及的所有相关锁定）以及将多个接收的消息作为一个集合处理而不是一次处理它是非常重要的。
监控SB可能会很痛苦。你基本上依赖一堆系统视图来告诉你发生了什么。孤立的消息很痛苦。只有很多小问题可以，好吧，getcha。
除了问题，并没有那么多，我认为它确实比我预期的更好。由于SB已集成到数据库中，因此没有单独的消息队列备份到数据库之外。这在事务上都是一致的。表现很好。这是一个很好的解决方案。
我会再次使用它并继续使用它。
答案 2 :(得分：5)
在我现在的公司，我们对SB的使用与其他海报有所不同。我们在SQL2005中主要使用SB作为管理工具。例如，我们使用它来管理对大量不可变数据库中存在的一小组可变表的更新。所有消息都在同一实例上运行的服务之间，并且消息量非常低。
我对SB的经验是，正确设置可能有些“繁琐”，正如您在问题中提到的那样，很难概述SB的状态，因为没有单一的监控工具。
尽管如此，我们发现它作为一种以可追溯和可靠的方式自动执行大量数据库管理任务的方法具有极大的价值。
答案 3 :(得分：2)
我最近考虑过将Service Broker用于一个项目，但是是的，决定转而使用MSMQ。
我们的架构由许多（集群）服务器组成，每个服务器都需要可靠地将信息写入单个SQL实例。
据我了解，SB仅适用于SQL到SQL通信，因此我们在每个群集盒上都需要一个SQL实例。我们觉得这有点不必要，因此使用MSMQ
说实话，我想不出我会使用SB的场景 - 我有兴趣了解你的场景，看看我是否遗漏了一些重要的东西。
答案 4 :(得分：-1)
Service Broker可用于需要在分布式体系结构中完成自动化的各种情况。 这些应用程序从各种设备接收事件并且需要可靠地完成处理。来自设备（检测）或传感器的事件用于处理自动化逻辑。在多个数据库或应用程序之间进行数据交换。
我希望SB的实施可以更强安全和可靠