.net - Azure 服务总线队列 ScheduledEnqueueTimeUtc 延迟

Question

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

上周五， azure 的中断导致该应用程序完全瘫痪。当我将其重新联机时，ScheduledEnqueueTimeUtc 总是导致至少 10 秒的延迟。例如，我生成一个 future 1 到 10 秒之间的日期时间。我将其设置为 ScheduledEnqueueTimeUtc，并且还将该时间作为我发送的消息的属性，当我在云服务 A 中收到消息时，我将该日期时间属性与消息的 EnqueuedTimeUtc 属性进行比较。这 2 次应该相当不错紧密地结合在一起，这就是直到上周五为止几个月来一直运作的方式。

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

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

Answer 1

来自ScheduledEnqueueTimeUtc Property's documentation :

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

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

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