使用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

回答