我们看到了一些使用服务总线和死信无法理解的行为，并且想知道是否有人可以向我们提供一些有关规则如何工作的见识。

如果我创建一个TTL为5分钟(" LongTopica"？)的主题，该主题有2个订阅，则为" Longa"？以及5分钟的TTL和" Shorta"？ TTL为5秒，然后向该主题发送测试消息，那么我们看到的是，我们没有在" Shorta"上收到一封死信。 5秒后，但大约1分钟后再做。因此，看来我可以用较短的TTL覆盖主题TTL，但这并不一定意味着它会在TTL到期时立即用死字母表示。

如果我创建一个TTL为5秒的主题(" ShortTopica")，该主题有2个订阅，则为" Longa"？以及5分钟的TTL和" Shorta"？ TTL为5秒，然后向该主题发送测试消息，那么我们看到的是，我们没有在" Shorta"上收到一封死信。 5秒钟后，但大约1分钟后，我们还会在a？Longa？上收到一条不道德的消息。大约一分钟后因此，看来我无法在预订中用更长的TTL覆盖主题TTL，但这再次并不一定意味着它会在TTL过期后立即被完全删除。

我们遇到的主题具有更长的TTL(3000天)，有时我们会看到没有从订阅中转发的消息，即使订阅的TTL为1分钟，它们也没有1.5小时的死信。

有人知道这是否是预期的行为吗？还是链接到有关邮件何时可能被死信的规则的链接？

当您在消息上设置死信信息时，它会告诉Service Bus消息何时应移动到死信队列或完成(又名删除)(取决于是否在邮件上启用了死信)。队列或订阅。如果队列或订阅上有活动的接收者，则死信时间将在几秒钟内与死信间隔匹配。当您仅发送消息时，系统以后台任务运行，该任务以常规节奏检查队列或预订。正如您通过实验发现的那样，此检查每60秒钟进行一次。

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

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

这时，您将不会看到频繁使用的队列和订阅的主动TTL行为。如果您有一条消息在超过2小时后到期，则该消息将不会移入死信队列，因为计时器不会在"空闲实体"上运行。当服务总线看到异常大量的使用时，此窗口可能会大大缩小-实体上只有2分钟的空闲时间，这将导致主动TTL计时器停止运行。