使用Azure服務總線隊列和BrokeredMessage.ScheduledEnqueueTimeUtc更新訂閱

我有一個訂閱模型，並希望執行與更新相關的邏輯，如發出新發票，發送電子郵件等。例如，用戶將在今天購買訂閱，而續約是在一年的時間。我最近一直在使用Azure隊列，並認爲它適用於這種續訂。使用Azure服務總線隊列和BrokeredMessage.ScheduledEnqueueTimeUtc更新訂閱

是否可以通過使用BrokeredMessage.ScheduledEnqueueTimeUtc（http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx）推送消息來使用Azure隊列來處理這樣的長期預定消息？

我已經將它用於短期，比如在1分鐘內發送通知，並且效果很好。

這樣，我甚至可以有多個進程監聽隊列，並確保只有一個進程執行更新邏輯。這將解決很多鎖定相關的問題，因爲這是通過租賃和相關功能內置Azure隊列的。

是的，您可以將其用於長期計劃，計劃的消息具有與正常計劃相同的擔保。但也有你需要知道的幾件事情：在隊列中，但沒有必要交付（幾百毫秒之內）

ScheduledEnqueueTimeUtc是當消息將是可用的時間，這取決於負載狀態隊列。所以對於業務流程來說很好，但不適用於時間敏感（毫秒）的使用。您的情況不是問題，除非您的訂閱取消對時間非常敏感。
它會影響您的存儲配額（不是真的與當前的配額問題，但如果你仔細想想幾年，這可能是一個問題）
據我所知，你不能ScheduledEnqueueTimeUtc之前訪問計劃的消息，他們是看不見的。

從技術的角度來看，這很好，但你的情況我也想對其他潛在的問題，如果你想一想年：

2014-11-13 17:53:05 b2zw2a

我正在考慮一個不同的方法來解決這個問題，因爲它可以像你說的那樣有很多凹陷。可能我試圖使用數據庫事務來達到同樣的目的。我的主要問題是沒有兩個進程會兩次處理相同的通知消息/更新。 –

不確定你是什麼規模的，但如果是合理的，你可以運行日常的工作，它可以處理續約或簡單地將續訂消息添加到服務總線隊列中。通過這種方式，您可以處理兩個世界 - 可管理的時間範圍和至少一次處理。 – b2zw2a

回答