Azure服务总线队列ScheduledEnqueueTimeUtc已延迟

Question

我遇到了一个奇怪的问题。我有一个云服务A，它将消息放入服务总线队列中，以供另一个云服务B读取。云服务B可能需要大约一秒钟的时间来处理它需要做的事情，然后它会将一条消息放回云服务A的队列中。当云服务B执行此操作时，它会使用ScheduledEnqueueTimeUtc将消息延迟大约1- 10秒。

上周五，azure宕机使这个应用程序完全停机。当我将其重新联机时，ScheduledEnqueueTimeUtc总是导致至少10秒的延迟。例如，我生成一个在未来1到10秒之间的日期时间。当我在云服务A中收到消息时，我将ScheduledEnqueueTimeUtc属性与消息的EnqueuedTimeUtc属性进行了比较，这两次应该非常接近，直到上周五，这是它几个月来的工作方式。

所以现在云服务B说它在1秒内将此消息放入队列。云服务A表示，它有12-14秒没有进入队列。在将消息放入队列时，我使用异步方法。如果我不使用ScheduledEnqueueTimeUtc，就不会有延迟，当我在云服务A中查看它们时，它们的时间非常接近。但如果我在未来设置ScheduledEnqueueTimeUtc，即使是1秒，它似乎也不会在队列中显示12-14秒。

我现在正在通过使用quartz.net而不是设置ScheduledEnqueueTimeUtc属性来安排消息来解决这个问题。但这似乎真的很奇怪，这种情况开始发生。

Answer 1

来自ScheduledEnqueueTimeUtc Property's documentation

“消息排队时间并不意味着消息将同时发送。消息将进入队列，但实际发送时间取决于队列的工作负载及其状态。”

该属性会导致消息不能立即传递。它不会在设定的时间之前交付，但不能保证它会在那个时候准确交付。

如果您需要高分辨率调度，Quartz可能是一个选择。您还可以评估作为移动服务预览的一部分的新job scheduler。

Answer 2

在某些边缘情况下，ShcheduledEnqueueTimeUtc功能最近出现了退化，这会导致您在上面看到的行为。这将在接下来的几天内修复，您应该会看到预期/原始行为。

根据队列的繁忙程度，计划的消息可能会有一些延迟，但在您上面提到的场景中使用是很好的。影响您的应用程序的任何功能回归都可以作为Azure的支持票证提出：http://www.windowsazure.com/en-us/support/contact/