我正在使用一個使用azure服務總線隊列的命令處理應用程序。 命令從網站發佈併發布到隊列中，隊列消息由輔助角色處理。處理包括根據隊列消息值從數據庫和其他源獲取數據並將其發送到不同的主題。流動是，在azure服務總線隊列中處理消息處理的選項
我在這裏面臨的挑戰是處理時間。有時它超過了最大消息鎖定時間段（5分鐘配置），因此消息被解鎖，並且它重新出現以使工作角色能夠拾取（考慮多個工作角色實例）。所以這會導致再次處理相同的消息。
我有什麼選擇來處理這種情況。
我曾經想過，
接收消息 - 添加到本地變量 - 完整的標記信息。 如果發生異常，再次將消息發送到隊列或單獨的隊列（讓我們說失敗的消息隊列）。第二個隊列 也意味着另一個工作者角色來處理它。
在處理過程中有一個運行的foreach循環。所以我想到 而不是使用Parallel.Foreach。但不知道多少時間 獲得它會給，並在使用 蔚藍平行時，也閱讀一些問題上的問題。
建議，修復歡迎。
您可能想要考慮使用Azure Queue，Azure隊列消息的最長租用時間爲7天，而Azure服務總線隊列租用時間爲5分鐘。
This msdn article描述了兩種Azure隊列類型之間的差異。
如果標準Azure隊列不包含您需要的所有功能，則可以考慮使用這兩種類型的隊列。
Aravind，你可以絕對使用SB隊列在這種情況下。使用最新的SDK，只要您正在繼續處理它，您就可以更新郵件上的鎖定。詳情見：http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.renewlock.aspx
這類似於更新可見性超時的Azure存儲隊列功能：http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.storage.queue.cloudqueue.updatemessage.aspx
看起來不錯選項。猜猜你必須有一個計時器並更新這個鎖。但目前卡住了Azure SDK 1.7。 – Aravind
無論您使用的是哪種Azure SDK版本，都可以使用以下NuGet包引用最新的Service Bus客戶端庫：http://nuget.org/packages/WindowsAzure.ServiceBus –
可以把火關任務與不斷更新的鎖你，而你心跳操作處理它。這正是我所做的。我描述了我的方法Creating a Task with a heartbeat
我曾考慮存儲和服務總線隊列，然後到達隊列。 – Aravind
如果您的處理將花費5分鐘以上，那麼sb隊列看起來不太適合您的問題，存儲隊列允許更長的處理時間。您建議的解決方案1看起來不太好，就好像角色/網絡在標記完成後關閉，那麼您將永遠不會有機會將其重新添加到隊列中。如果服務總線功能對您至關重要，請考慮從sb隊列中刪除消息，將其添加到存儲隊列中，然後將其從sb隊列中刪除，然後可以從存儲隊列中處理消息（如果需要，可以使用同一個角色） – Rob