检测和删除 Azure 服务总线上的孤立队列、主题或订阅

Question

如果由于崩溃或其他异常终止（实例重启等），不再有任何发布者或订阅者读取或写入队列、主题或订阅，那么该队列/主题/订阅是否有效孤立？

我通过创建几个队列来测试这个，然后终止应用程序。很久以后，这些队列仍然在服务总线上。似乎他们会永远留在那里。如果我们想要这种行为那就太好了，但在这种情况下，我们没有。

我们如何检测和删除这些队列、主题和订阅？它们将计入 Azure 限制等，并且每次实例重新启动/修补/崩溃时，我们都无法拥有这些孤立进程。

如果它有助于使问题更清楚，这是一种独特的情况，其中队列/主题/订阅具有特殊名称或特殊过滤器，并且在有限的时间内发布者 (1) 和订阅者 (1) 的集合非常有限。这不是我们想要生存能力的情况。这些是特定于实例的响应通道。我们是使用队列还是订阅并不重要。如果实例消失了，那么对该队列（或订阅）的需求也消失了。

这是解决方案的一部分，其中每个 Web 角色都有一个它监视的专用响应通道。在任何时候，这个 Web 角色都可能有数十个通过其他消息传递通道（队列/主题）未决的请求，并且它正在多个线程上等待答案。我们需要将响应返回到放置消息的线程，以便 web 角色可以响应调用者。在这种情况下，仅仅有一个基于机器的订阅是不好的，因为它会接收其他线程的消息。我们需要每个发布线程建立一个专用的响应通道，以便该通道上唯一的东西就是该线程的响应。

即使我们使用订阅（带有某种与实例相关的过滤器）对订阅进行长轮询接收操作，如果网络角色实例死亡，该订阅将成为孤立的，对吗？

这个问题可以归结为：如果队列/主题/订阅没有更多的发布者或订阅者，那么该服务实际上是孤立的。如何检测和清理这些孤儿？

Answer 1

在这种情况下，您正在寻找本质上“动态”的队列/订阅。它们将根据使用情况来创建和删除，而不是这些实体当前的显式供应模型。服务总线为您提供了执行创建/删除操作的 API，以便您可以将这些操作适当地插入到角色 OnStart/OnStop 事件中。如果这些操作由于某种原因失败，那么孤立实体将存在。同样，您可以根据实体名称的某些唯一标识符对它们运行清理操作。可以在这里看到这样的示例：http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/

在不久的将来，我们将向队列/主题/订阅添加更多元数据和查询功能，以便您可以查看上次访问它们的时间并做出清理决策。