一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選擇的隊列中都有一個滿載而歸的顧客排在您前面，他/她購買的很多商品都需要核實價格，而且要使用第三方遠期支票進行付款。在輪到您結帳之前，可能在您開始排隊時還沒有出門的顧客都已經為他們購買的商品付完了款。這個例子說明了使用多個隊列時的一個問題：即，如果排在前面的任務需要很長時間才能處理完，後面的任務將無法得到及時處理。
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
>>>更多專題請看SQL Server專題一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
>>>更多專題請看SQL Server專題一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選擇的隊列中都有一個滿載而歸的顧客排在您前面，他/她購買的很多商品都需要核實價格，而且要使用第三方遠期支票進行付款。在輪到您結帳之前，可能在您開始排隊時還沒有出門的顧客都已經為他們購買的商品付完了款。這個例子說明了使用多個隊列時的一個問題：即，如果排在前面的任務需要很長時間才能處理完，後面的任務將無法得到及時處理。
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
>>>更多專題請看SQL Server專題
一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。
與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？
在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？
既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，
您正在看的SQLserver教程是:SQL Server 2005 Service Broker 初探(1)。如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選擇的隊列中都有一個滿載而歸的顧客排在您前面，他/她購買的很多商品都需要核實價格，而且要使用第三方遠期支票進行付款。在輪到您結帳之前，可能在您開始排隊時還沒有出門的顧客都已經為他們購買的商品付完了款。這個例子說明了使用多個隊列時的一個問題：即，如果排在前面的任務需要很長時間才能處理完，後面的任務將無法得到及時處理。
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
>>>更多專題請看SQL Server專題
一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？
在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？
既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選擇的隊列中都有一個滿載而歸的顧客排在您前面，他/她購買的很多商品都需要核實價格，而且要使用第三方遠期支票進行付款。在輪到您結帳之前，可能在您開始排隊時還沒有出門的顧客都已經為他們購買的商品付完了款。這個例子說明了使用多個隊列時的一個問題：即，如果排在前面的任務需要很長時間才能處理完，後面的任務將無法得到及時處理。
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
>>>更多專題請看SQL Server專題
一、引言
SQL Server 2005 的一個主要成就是可以實現可靠、可擴展且功能完善的數據庫應用程序。
與 .Net Framework 2.0 公共語言運行庫 (CLR) 的集成使開發人員可以將重要的業務邏輯與存儲過程合並，而 T-SQL 和 XML 中的新增功能擴展了數據操作的可用范圍以及開發人員可用的存儲功能。另一個重要功能是 SQL Server Service Broker，它為數據庫應用程序增加了可靠、可擴展、分布式異步功能。
二、為什麼要編寫異步排隊操作？
在開發 SQL Server 2005 時，我們與成功開發過大型可擴展數據庫應用程序的人員進行了交談。結果發現他們幾乎所有的應用程序中都有一個或多個操作是以異步排隊方式執行的。股票交易系統中的結算活動是排隊的，這樣可以在後台進行結算，在前端處理其他交易。訂單輸入系統中的發貨信息放在一個排隊中，稍後將由另一台服務器（通常位於其他位置）上運行的發貨系統讀取。旅行預訂系統在客戶填寫完路線後再進行實際的預訂，並在預訂完成後發送確認電子郵件。在所有這些示例中，許多工作都是通過異步方式完成的，從而提高了系統的響應速度，因此用戶無須等待工作完成就可以收到響應。
在大多數大型系統中，經過仔細分析後都可以發現，許多處理都可以通過異步方式完成。雖然應用程序中的排隊任務無須立即完成，但系統必須確保這些任務能夠可靠地完成。Service Broker 使異步排隊任務的執行可靠並且易於實現。
使應用程序中的部分任務異步執行的另一個優勢是這些任務的處理工作可以在資源可用時完成。如果訂單輸入系統中的發貨任務可以從隊列中執行，發貨系統就無需具有處理峰值訂單負載的能力。在許多訂單輸入系統中，峰值訂單率可能是平均訂單率的兩倍或三倍。由於訂單輸入系統必須具有處理峰值負載的能力，因此大量處理能力在很大一部分時間內都處於閒置狀態。如果在出現峰值時對異步任務進行排隊並在空閒時執行，將顯著提高系統的利用率。
三、為什麼排隊應用程序難於編寫？
您正在看的SQLserver教程是:SQL Server 2005 Service Broker 初探(1)。
既然異步排隊應用程序具有許多優勢，為什麼不以這種方式編寫所有應用程序？這是因為編寫異步排隊應用程序相當困難！許多嘗試在應用程序中使用數據庫表作為隊列的開發人員發現，實際操作遠比想象的困難。作為隊列的表中包含多個進程，包括同時插入、讀取和刪除幾條記錄。這將帶來並發問題、降低系統性能並導致頻繁死機。盡管許多開發人員都成功地解決了這些難題，但實際操作卻非常困難。Service Broker 通過使隊列成為 SQL Server 2005 數據庫中的第一級數據庫對象解決了這些問題。編寫隊列的大多數難題都已解決，因此開發人員可以專注於編寫異步應用程序，而不是編寫排隊基礎結構。本文的其余內容將討論編寫排隊應用程序涉及到的難題，並解釋 Service Broker 如何幫助您解決這些難題。
在許多異步排隊應用程序中，排隊的消息實際上是有價值的業務對象。例如在訂單輸入系統中，如果將發貨信息放入隊列中以便稍後處理，那麼丟失排隊的數據將意味著無法按訂單發貨。許多可靠的消息傳送系統都將消息存儲在文件系統中，因此磁盤驅動器的損壞將導致消息丟失。Service Broker 將消息存儲在隱藏的數據庫表中，因此 SQL Server 為保護數據而提供的所有數據完整性功能同樣可用於保護排隊的消息。如果使用數據庫鏡像進行故障恢復，當因數據庫故障而轉移到第二個數據庫後，所有消息都會轉移到第二個數據庫中，這樣 Service Broker 應用程序將繼續運行而不會丟失任何數據。
多讀取器隊列是一種擴展異步應用程序的最有效的方式。為證明這一點，我將通過大家都熟悉的兩個示例說明如何進行排隊。
大多數雜貨店都可以增設多個隊列。每個收銀台都有其自己的隊列，因此要購買某些商品，您需要選擇一個隊列。如果您像我一樣，大多數時候選擇的隊列中都有一個滿載而歸的顧客排在您前面，他/她購買的很多商品都需要核實價格，而且要使用第三方遠期支票進行付款。在輪到您結帳之前，可能在您開始排隊時還沒有出門的顧客都已經為他們購買的商品付完了款。這個例子說明了使用多個隊列時的一個問題：即，如果排在前面的任務需要很長時間才能處理完，後面的任務將無法得到及時處理。
使用多個隊列的另一個主要問題是，添加一個隊列後需要在各隊列之間重新分配任務，在隊列之前來回移動任務可能會浪費很多時間。還以上面的雜貨店為例，當一個新的收銀台開始工作時，想象一下許多顧客推著購物車蜂擁而至的場面吧。
