我们在服务总线和死信中看到了一些我们无法理解的行为，并且想知道是否有人可以让我们深入了解规则的工作原理。
如果我创建一个 TTL 为 5 分钟的主题(“LongTopic”)，它有 2 个订阅，“长”的 TTL 也为 5 分钟，“短”的 TTL 为 5 秒，然后发送测试消息到该主题，然后我们看到的是，5 秒后我们没有收到“Short”的死信，但大约 1 分钟后收到。所以看来我可以用更短的 TTL 来覆盖主题 TTL，但这并不一定意味着 TTL 到期后它会立即变成死字。
如果我创建一个 TTL 为 5 秒的主题(“ShortTopic”)，它有 2 个订阅，“长”的 TTL 也为 5 分钟，“短”的 TTL 为 5 秒，然后发送测试消息到该主题，然后我们看到的是，5 秒后我们没有收到“Short”上的死信，但大约 1 分钟后收到了，并且大约 1 分钟后我们还收到了“Long”上的死信消息以及。因此，我似乎无法在订阅中使用更长的 TTL 来覆盖主题 TTL，但这并不一定意味着 TTL 到期后它将立即成为死信。
我们的主题具有更长的 TTL(3000 天)，有时我们会看到未从订阅转发的消息，尽管订阅的 TTL 为 1 分钟，但在 1.5 小时内未发生死信。
有人知道这是否是预期的行为吗？或者有关于何时邮件可能成为死信的规则的链接？
最佳答案
当您在消息上设置死信信息时，它会告诉服务总线消息何时应移动到死信队列或完成(也称为删除)——选择取决于是否在消息上启用了死信队列或订阅。如果队列或订阅上有事件接收者，则死信时间将在几秒内匹配死信间隔。当您只是发送消息时，系统会运行一个后台任务，定期检查队列或订阅。正如您通过实验发现的那样，此检查每 60 秒进行一次。
您的下一个问题可能是“为什么这不像我想要的那样？”服务总线在设计时进行了大量优化，以确保所有消息都能持久发送，并且发送和接收尽可能快。这意味着我们花费了大量的工程时间来确保主要场景(发送/接收/浏览消息)的持久性和快速性。
您所看到的行为(我们称之为“主动 TTL”)实际上是相当新的。它于 2013 年 4 月首次引入 Windows Azure 服务。在此之前，用户必须主动接收队列或订阅才能强制簿记代码运行。
目前，您将看不到轻度使用的队列和订阅的主动 TTL 行为。如果您有一条消息在 2 小时以上过期，则该消息不会移入死信队列，因为计时器不会在“空闲实体”上运行。当服务总线的使用量异常高时，此窗口可能会大大缩小 - 实体上低至 2 分钟的空闲时间都会导致主动 TTL 计时器停止运行。
关于azure - 死信规则如何在 azure 托管服务总线中发挥作用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18149184/