在azure托管的servicebus中，死信规则是如何工作的？

我们在servicebus和deadletters中看到了一些我们无法理解的行为，我们想知道是否有人能给我们一些关于规则如何工作的见解

如果我创建了一个TTL为5分钟（“LongTopic”）的主题，它有两个订阅，“Long”的TTL为5分钟，“Short”的TTL为5秒，然后向该主题发送一条测试消息，那么我们看到的是，我们不会在5秒后收到“Short”上的死信，而是在大约1分钟后收到。因此，似乎我可以用一个较短的TTL覆盖主题TTL，但这并不一定意味着TTL到期后它将立即被死信覆盖

如果我创建了一个TTL为5秒的主题（“ShortTopic”），它有两个订阅，“Long”和“Short”分别有5分钟和5秒的TTL，然后向该主题发送一条测试消息，那么我们看到的是，我们不会在5秒后收到关于“Short”的死信，而是在大约1分钟后收到，大约一分钟后，我们也会在“Long”上收到一条写着死信的信息。因此，我似乎无法在订阅中用更长的TTL覆盖主题TTL，但这也不一定意味着在TTL过期时它会立即被死信覆盖

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

---

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

当您在消息上设置死信信息时，它告诉服务总线消息何时应该移动到死信队列或何时应该完成（也称为删除）——选择取决于队列或订阅上是否启用了死信。如果队列或订阅上有活动接收器，则死信时间将在几秒钟内与死信间隔匹配。当您刚刚发送消息时，系统会运行后台任务，以常规的节奏检查队列或订阅。正如你在实验中发现的，这种检查每60秒进行一次

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

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

此时，您将不会看到少量使用的队列和订阅的主动TTL行为。如果有一条消息在>2小时后过期，则该消息不会移动到死信队列中，因为计时器不会在“空闲实体”上运行。当服务总线出现异常高的使用量时，此窗口可能会大幅缩小——实体上的2分钟空闲时间低到2分钟，就会导致主动TTL计时器停止运行