當我參加了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