6

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

上周五，天蓝色的中断使该应用程序完全瘫痪。当我重新上线时，ScheduledEnqueueTimeUtc 总是会导致至少 10 秒的延迟。例如，我生成一个未来 1 到 10 秒之间的日期时间。我将其设置为 ScheduledEnqueueTimeUtc，并将该时间作为我发送的消息的属性，当我在云服务 A 中收到消息时，我将该日期时间属性与消息的 EnqueuedTimeUtc 属性进行比较。这两次应该很漂亮紧密相连，直到上周五为止，这就是它几个月来一直工作的方式。

所以现在云服务 B 说它会在 1 秒内将此消息放入队列。云服务 A 说它在 12-14 秒内没有进入队列。我在将消息放入队列时使用异步方法。如果我不使用 ScheduledEnqueueTimeUtc，则没有延迟，当我在云服务 A 中查看它们时，时间匹配得足够近。但如果我将 ScheduledEnqueueTimeUtc 设置为未来 1 秒，它似乎不会出现在队列中 12 -14 秒。

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

4

2 回答 2

6

从ScheduledEnqueueTimeUtc 属性的文档：

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

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

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

于 2013-03-01T17:13:12.217 回答
3

最近在 ShcheduledEnqueueTimeUtc 功能中有一个回归，在某些边缘情况下会导致您在上面看到的行为。这将在接下来的几天内修复，您应该会看到预期/原始行为。

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

于 2013-03-08T21:33:15.747 回答