0

我们看到一些我们无法通过 servicebus 和 deadletters 理解的行为，并且想知道是否有人可以让我们深入了解规则的工作原理。

如果我创建一个 TTL 为 5 分钟的主题（'LongTopic'），它有 2 个订阅，'Long' 的 TTL 也为 5 分钟，'Short' 的 TTL 为 5 秒，然后向主题，那么我们看到的是，我们在 5 秒后没有在“Short”上收到死信，而是在大约 1 分钟后收到。所以似乎我可以用更短的 TTL 覆盖主题 TTL，但这并不一定意味着它会在 TTL 到期后立即被死信。

如果我创建一个 TTL 为 5 秒的主题（'ShortTopic'），它有 2 个订阅，'Long' 的 TTL 也为 5 分钟，'Short' 的 TTL 为 5 秒，然后向主题，那么我们看到的是，我们在 5 秒后没有在“短”上收到死信，而是在大约 1 分钟后收到了死信，而且在大约一分钟后，我们也在“长”上收到了死信。因此，我似乎无法在订阅中使用更长的 TTL 覆盖主题 TTL，但这并不一定意味着它会在 TTL 到期后立即死信。

我们的主题具有更长的 TTL（3000 天），有时我们会看到没有从订阅转发的消息，尽管订阅的 TTL 为 1 分钟，但在 1.5 小时内没有死信。

有谁知道这是否是预期的行为？或者有一个关于消息何时可能是死信的规则的链接？

4

1 回答 1

2

当您在消息上设置死信信息时，它会告诉服务总线消息何时应该移动到死信队列或完成（也称为删除） - 选择取决于是否在队列或订阅上启用死信. 如果您在队列或订阅上有一个活动的接收者，那么死信时间将在几秒钟内匹配死信间隔。当您只是发送消息时，系统会运行一个后台任务，该任务会定期检查队列或订阅。正如您在实验中发现的那样，此检查每 60 秒发生一次。

您的下一个问题可能是“为什么这不符合我的要求？” 服务总线经过大量优化设计，以确保所有消息都被持久发送，并且发送和接收尽可能快。这意味着我们需要花费大量的工程时间来保证主要场景（发送/接收/浏览消息）的持久性和快速性。

您所看到的行为，我们称之为“主动 TTL”，实际上是相当新的。它于 2013 年 4 月首次引入 Windows Azure 服务。在此之前，用户必须主动接收队列或订阅才能强制运行记账代码。

此时，您将看不到轻度使用的队列和订阅的主动 TTL 行为。如果您的消息在 2 小时后过期，则该消息不会移入死信队列，因为计时器不会在“空闲实体”上运行。当服务总线看到异常高的使用量时，此窗口可能会显着缩小 - 实体上低至 2 分钟的空闲时间将导致主动 TTL 计时器停止运行。

于 2013-08-12T16:23:14.193 回答