使用SQL Server Service Broker在.NET應用程序之間進行消息傳遞

我正在考慮在兩個.NET應用程序之間使用Service Broker進行消息傳遞，其中一個應用程序需要可靠地向另一個應用程序發送消息。我有一個很好的主意，看看這是如何看待發起人的一面。使用SQL Server Service Broker在.NET應用程序之間進行消息傳遞

但是，消費者應用程序需要從隊列中加載消息，進行一些處理，然後確認處理進行得很順利。處理可能會失敗，在這種情況下，我需要重試消息。我還需要保留爲歷史目的而處理的所有消息。

據我所知，當我進行RECEIVE時，消息從隊列中被刪除。那麼消費者應用程序在失敗的情況下應該做什麼？再次將消息推入隊列？我可以將郵件標記爲「正在處理中」，然後在我的任務成功完成後將其刪除？

我該如何使用Service Broker對此進行建模？

來源

2011-10-20 driis

Service Broker是一件好事 - 如果您需要在SQL Server內部或之間進行消息傳遞。對於兩個.NET應用程序之間的通信，我會看看WCF而不是SQL Server Service Broker ... –

我需要一個持久的異步隊列。如果其中一個或兩個應用程序死亡，排隊的項目不會丟失。 WCF中有什麼可以給我的嗎？（不幸的是）MSMQ或其他分佈式消息隊列目前不適用於此項目。 – driis

爲什麼MSMQ不是一個選項？它在那裏，它與每個Windows服務器都是免費的，它與WCF很好地集成在一起......它將完美適合您的需求，我相信... –

您可以在事務中接收事務並在發生錯誤時回滾事務。請注意，內置的有毒消息處理將在針對給定消息進行5次這種回滾後禁用隊列。

來源

2011-10-20 20:48:49

每個單獨的任務可能需要幾秒鐘才能完成。這不是不好的做法，並導致隊列中的爭奪讓交易持續了很久？ – driis

@driis：Queue和RECEIVE特別適用於存在長時間事務的情況：新消息的排隊不會與RECEIVE事務處理的鎖衝突，併發RECEIVE可以並行進行。請參閱http://msdn.microsoft.com/en-us/library/ms171615.aspx –

如果處理是*真*長，那麼您應該出隊，更新某些狀態表，**入隊定時器*，提交併開始處理。如果成功，重置計時器。如果你失敗了，定時器會觸發，你的應用程序邏輯將讀取已保存的狀態，**排隊一個新的定時器**，提交併再次嘗試。請參閱http://msdn.microsoft.com/en-us/library/ms187804.aspx –

使用SQL Server Service Broker在.NET應用程序之間進行消息傳遞

回答

相關問題