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

Question

如果由于崩溃或其他异常终止(实例重新启动等)而不再有任何发布者或订阅者读取或写入队列、主题或订阅，那么该队列/主题/订阅实际上是孤立的吗？

我通过创建一些队列，然后终止应用程序来对此进行测试。很长一段时间后，这些队列仍在服务总线上。看来他们只会永远留在那里。如果我们想要这种行为那就太好了，但在这种情况下，我们不想要。

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

如果这有助于使问题更清晰，那么这是一种独特的情况，其中队列/主题/订阅具有特殊名称或特殊过滤器，以及一组非常有限的发布者 (1) 和订阅者(1) 限时。这不是我们想要生存的情况。这些是特定于实例的响应 channel 。我们使用队列还是订阅并不重要。如果实例消失了，那么对该队列(或订阅)的需求也消失了。

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

即使我们使用订阅(带有某种与实例相关的过滤器)对订阅执行长轮询接收操作，如果 Web 角色实例终止，该订阅也会被孤立，对吗？

这个问题可以归结为:如果队列/主题/订阅不再有发布者或订阅者，则该服务实际上是孤立的。如何发现并清理这些孤儿？

Answer 1

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

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