Compartilhar via

Azure Service Bus - 消息过期（生存时间）

消息中的有效负载，或者由消息传递给接收方的命令或查询，几乎总是附带了某种形式的应用程序级过期截止时间。 此截止时间过后，便不再传送内容，或不再执行请求的操作。 在开发和测试环境中，队列和主题通常用于应用程序或其部分的部分运行。此时，我们希望自动删除遗留的测试消息，以便下次测试运行可以在清晰的状态下开始。

存活时间和到期时间 (UTC)

可以通过设置指定相对持续时间的 生存时间 系统属性来控制任何单个消息的过期时间。 将消息排队到实体时，过期时间将变为绝对的瞬间。 此时，expires-at-utc 属性取值为 enqueued-time-utctime-to-live。 当没有客户端主动侦听时，代理消息的生存时间 [TTL] 设置不被强制执行。

注意

代理可能不会立即删除已过期的消息。 代理可以根据消息过期时实体是否处于活动状态来选择延迟这些消息的过期。 因此，在使用消息过期时，您可能会观察到不正确的消息计数，甚至可能会在速览操作中看到这些消息。 接收消息时，过期的消息不会被包括。

在 expires-at-utc 时刻过后，消息将变为不可检索。 当前锁定以进行传送的消息不会受到到期的影响。 仍会正常处理这些消息。 如果锁已过期或者消息被丢弃，则过期时间立即生效。 消息被锁定时，应用程序可以拥有已过期的消息。 应用程序是要继续处理还是选择丢弃消息，则由实施者决定。

以毫秒或秒为单位的极低 TTL 可能会导致消息在接收方应用程序收到消息之前过期。 请考虑适用于你的应用程序的最高 TTL。

定时消息

对于 计划消息，可以指定希望消息出现在队列中以供检索的排队时间。 将消息发送到Service Bus的时间与消息排队的时间不同。 消息过期时间取决于排队时间，而不是消息发送到Service Bus的时间。 因此，过期时间（UTC） 仍然是 入队时间 + 生存时间。

例如，如果设置为 ScheduledEnqueueTimeUtc 5 分钟 UtcNow和 TimeToLive 10 分钟，则消息将在 5 + 10 = 15 分钟后过期。 消息在 5 分钟后出现在队列中，然后启动 10 分钟计时器。

实体级过期时间

所有发送到队列或主题的消息都将遵循您在实体级设置的默认过期时间。 还可以在创建期间在门户中设置此过期时间，并在以后对其进行调整。 默认过期适用于未显式设置生存时间的实体的所有消息。 默认过期时间还充当生存时间值的上限。 如果消息的生存时间比默认值长，则系统会在将消息入队列之前，悄无声息地将其调整为默认消息生存时间值。

expires-at-utc 属性是有意设计的。 如果未设置消息 TTL，并且仅设置实体 TTL，则 expires-at-utc 是一个计算值，该值会在 Receive/Peeklock 路径中计算，而不会在查看路径中计算。 如果消息具有 TTL，系统会在发送消息时计算expires-at-utc并存储。 在这种情况下，Peek 返回正确的 expires-at-utc 值。

注意

可以选择将过期的消息移动到 死信队列。 可以通过编程方式或使用 Azure 门户来配置此设置。 如果使选项处于禁用状态，则将删除过期的消息。 可以通过评估中转站存储在用户属性部分中的 死信原因 属性来区分过期消息和其他已经移动到死信队列的死信消息。

如果消息在锁定状态下受到保护以防止过期，并且实体上已设定相应的标志，则当锁被放弃或过期时，该消息会被移到死信队列。 但是，如果消息成功解决，系统不会移动消息。 解决假设应用程序已成功处理消息，尽管名义过期。 有关消息锁和处置的详细信息，请参阅消息传输、锁和处置。

生存时间与过期自动（或事务性）死信策略的结合是确保在截止日期到达时，作业能够被处理者或一组处理者检索并进一步处理的重要工具。

例如，假设某个网站需要在规模受限的后端上可靠执行作业，并且偶尔会遇到流量高峰，或者需要受到隔离，以防止该后端在某段时间遇到可用性问题。 在一般情况下，所提交用户数据的服务器端处理程序会将信息推入队列，随后在回复队列中接收确认已成功处理事务的回复。 如果出现流量高峰并且后端处理程序无法及时处理其积压工作项，则已过期的作业会返回到死信队列中。 可以告知交互用户请求的操作所花费的时间比平时稍长，然后可将请求放到不同队列的处理路径，并通过电子邮件将其中的最终处理结果发送给用户。

临时实体

可以将Service Bus队列、主题和订阅创建为临时实体。 当这些实体未在指定时间段内使用时，系统会自动删除这些实体。

自动清理在开发和测试方案中非常有用，其中实体是动态创建的，并且由于测试或调试运行的一些中断，在使用后不会清理。 当应用程序创建动态实体（例如回复队列）用于在 Web 服务器进程或者生存期相对较短的对象（对象实例消失时难以可靠清理这些实体）中接收响应时，此功能也很有用。

通过在实体 上的空闲属性上设置自动删除 来启用该功能。 将此属性设置为在系统自动删除实体之前必须处于空闲状态（未使用）的持续时间。 此属性的最小值为 5 分钟。

重要

将命名空间或更高级别的Azure Resource Manager锁级别设置为 CanNotDelete 不会阻止删除具有 AutoDeleteOnIdle 的实体。 如果不希望删除实体，将 AutoDeleteOnIdle 属性设置为 DataTime.MaxValue。

空闲

下面是实体的空闲状态（队列、主题和订阅）：

实体 被视为空闲的情况
队列
  • 无发送
  • 无信号接收
  • 无队列更新
  • 没有预定的消息
  • 不可浏览或预览
主题
  • 无发送
  • 无关于该主题的更新
  • 没有预定的消息
  • 对主题的订阅没有进行任何操作（请见下一行）
订阅
  • 无信号接收
  • 无订阅更新
  • 订阅中未添加任何新规则
  • 不可浏览或预览

重要

如果在队列或订阅上设置自动转发，这就等同于接收方自动从队列或订阅执行接收操作。 这些实体并非闲置。

SDK

使用软件开发工具包（SDK）设置生存时间属性。

相关内容

如果尚不熟悉Service Bus概念，请参阅Service Bus概念和Service Bus队列、主题和订阅。

若要了解Azure Service Bus的高级功能，请参阅高级功能的Overview。

  • Last updated on