我遇到了一个奇怪的问题。我有一个云服务A，它将消息放入服务总线队列，供另一个云服务B读取。云服务B可能需要大约一秒钟来处理它需要做的事情，然后它将消息放回到云服务A的队列中。当云服务B执行此操作时，它使用ScheduledEnqueueTimeUtc来延迟大约1到10秒在消息上。
上周五，蔚蓝的停电使这个应用程序完全失效。当我将其重新联机时，ScheduledEnqueueTimeUtc始终会导致至少10秒的延迟。例如，我将来生成一个介于1到10秒之间的日期时间。我将其设置为ScheduledEnqueueTimeUtc并且我还将该时间作为我正在发送的消息的属性，我将该datetime属性与我在云服务A中收到它时的消息的EnqueuedTimeUtc属性进行比较。这两次应该很漂亮这是他们在上周五之前一直工作的方式。
所以现在云服务B说它在1秒内将此消息放入队列。云服务A表示它没有进入队列12-14秒。我在将消息放入队列时使用异步方法。如果我不使用ScheduledEnqueueTimeUtc没有延迟，当我在云服务A中查看它们时，时间匹配得足够接近。但如果我将来设置ScheduledEnqueueTimeUtc甚至1秒，它似乎不会出现在队列中12 -14秒。
我现在正在使用quartz.net来安排消息，而不是设置ScheduledEnqueueTimeUtc属性。但这种情况开始发生似乎很奇怪。
答案 0 :(得分：6)
来自ScheduledEnqueueTimeUtc Property's documentation：
“消息获取时间并不意味着消息将同时发送。它将被排队，但实际发送时间取决于队列的工作负载及其状态。”
该属性导致消息无法立即传递。它不会在 >设定的时间之前发送，但无法保证在那时完全。
如果您需要高分辨率调度，Quartz可能是一个选项。您还可以评估属于移动服务预览的新job scheduler。
答案 1 :(得分：3)
最近在ShcheduledEnqueueTimeUtc功能中出现了回归，在某些边缘情况下会导致您在上面看到的行为。这将在接下来的几天内修复，您应该看到预期/原始行为。
根据队列的繁忙程度，计划的消息可能会有一些滞后，但在上面提到的场景中可以使用。影响您的应用程序的任何功能回归都可以作为Azure支持票证提出：http://www.windowsazure.com/en-us/support/contact/