Azure 服务总线中的消息延迟

当队列或订阅客户端收到它愿意处理的消息时，由于特殊情况，目前无法处理，客户端可以将消息的检索延迟到以后的某个时间点。 该消息将保留在队列或订阅中，但会标记为暂停处理。

何时使用消息延迟

延迟是专门针对工作流处理方案设计的功能。 工作流框架可能要求按特定顺序处理某些操作。 他们可能需要推迟处理一些收到的消息，直到其他消息事先通知的工作完成。

一个简单的说明示例是订单处理序列，在匹配的采购订单从店面传播到履行系统之前，外部支付提供商的付款通知会出现在系统中。 在这种情况下，履行系统可能会延迟处理付款通知，直到有订单与之关联。 在汇合场景中，来自不同来源的消息会推动工作流向前执行，实时执行顺序可能是正确的，但反映结果的消息可能会乱序到达。

延迟有助于将消息从到达顺序重新排序到可以处理的顺序，同时在需要推迟处理时将这些消息安全地保留在消息存储中。

如果某条消息因用于处理该消息的特定资源暂时不可用而无法处理，但又不应暂停消息处理，则可以先将该消息暂时搁置几分钟。 请记住要在几分钟内发布的 计划消息 中的序列号，并在计划消息到达时重新检索延迟的消息。 如果消息处理程序依赖于数据库进行所有操作，并且该数据库暂时不可用，请不要使用延迟。 相反，请完全暂停接收消息，直到数据库再次可用。

检索延迟的消息

已延迟处理的消息与所有其他活动消息一样保留在主队列中（不同于位于子队列中的死信消息），但无法再通过常规接收操作接收。 如果应用程序无法追踪这些消息，则可以通过 消息浏览或速览 来发现延迟消息。

若要检索延迟的消息，所有者负责在延迟消息时记住 序列号 。 任何接收方，只要知道延迟消息序列号，之后都可以通过使用将序列号作为参数的接收方法来接收消息。 有关序列号的详细信息，请参阅消息序列化和时间戳。

注意

在客户端应用尝试使用 API 和序列号接收消息之前，延迟消息不会过期并自动移动到死信队列。 此行为是特意这样设计的。 当客户端尝试检索延后消息时，系统会检查其过期状态，如果该消息已经过期，则会将其移至死信队列。 仅当为实体（队列或订阅）启用死信功能时，过期消息才会移至死信子队列。

延迟消息的主要行为

  • 延迟消息位于主队列中，而不在子队列中。
  • 必须使用消息的 序列号 来检索延迟的消息。
  • 可以通过 消息浏览（速览）发现延迟消息。
  • 在客户端尝试接收消息之前，延迟消息不会过期。
  • 仅当客户端调用带有序列号的接收 API 时，才会进行过期检查。

后续步骤

尝试采用所选语言的示例，了解 Azure 服务总线功能。

相关内容

  • Last updated on