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

【问题标题】：Detect and Delete Orphaned Queues, Topics, or Subscriptions on Azure Service Bus检测和删除 Azure 服务总线上的孤立队列、主题或订阅
【发布时间】：2012-09-08 22:03:09
【问题描述】：

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

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

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

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

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

即使我们使用 Subscriptions（带有某种与实例相关的过滤器）对 Subscription 执行长轮询接收操作，如果 Web 角色实例死亡，该 Subscription 也会成为孤立的，对吗？

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

【问题讨论】：

我们能否澄清一下您所说的是 Azure 中的队列（云中的 SB）或 Windows Server 的本地服务总线队列（服务总线 1.0 Beta）？

标签： azure appfabric servicebus azure-appfabric

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

服务总线队列是使用“代理消息传递”基础架构构建的，该基础架构旨在集成可能跨越多个通信协议、数据合同、信任域和/或网络环境的应用程序或应用程序组件。这允许一种机制与持久消息传递进行可靠通信。

如果客户端（发布者）将消息发送到服务总线队列然后崩溃，则消息将存储在队列中，直到消费者从队列中读取消息。此外，如果您的消费者死亡并重新启动，它只会轮询队列并获取任何等待它的工作（您可以横向扩展并让多个消费者从队列中读取以增加吞吐量），服务总线队列允许您通过以下方式解耦您的应用程序类似于本地 MSMQ（或其他排队技术）的持久云网关。

我真正想说的是，您不会得到孤立队列，您可能会收到需要处理的中毒消息，这篇博文提供了一些非常详细的信息：服务总线队列及其容量和配额可能会让你更好地理解http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx

Re：队列管理，您可以通过 Visual Studio（1.7 SDK 和工具）或有一个名为 Service Bus Explorer 的出色工具来完成此操作，这将使您的队列管理工作更轻松：http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a

*请注意，默认的最大队列数为 10,000（每个服务命名空间，可以通过支持电话增加）

【讨论】：

感谢您的回复。我的问题一般不是关于队列的持久性。我会改写的。

【解决方案3】：

正如 Abhishek Lai 所说，不支持孤儿检测功能。

孤儿检测可以通过多种方式在外部实现。例如，每当您发送/接收消息时，更新 SQL 数据库中的时间戳以指示队列/热带/订阅仍处于活动状态。然后可以使用此时间戳来确定孤儿。

【讨论】：

【解决方案4】：

如果您的进程很可能会崩溃，那么队列中的消息传递将会出现问题，但是队列仍可用于处理您的请求。描述了使用 Windows Azure 服务总线队列处理应用程序崩溃和不可读消息here：

服务总线提供的功能可帮助您从应用程序中的错误或处理消息的困难中优雅地恢复。如果接收方应用程序由于某种原因无法处理消息，那么它可以在收到的消息上调用 Abandon 方法（而不是 Complete 方法）。这将导致服务总线解锁队列中的消息，并使其可以被同一个消费应用程序或另一个消费应用程序再次接收。

如果应用程序在处理完消息后但在发出 Complete 请求之前崩溃，则消息将在应用程序重新启动时重新传递给应用程序。这通常称为至少一次处理，即每条消息将至少处理一次，但在某些情况下可能会重新传递相同的消息。如果场景不能容忍重复处理，那么应用程序开发人员应该向他们的应用程序添加额外的逻辑来处理重复的消息传递。这通常使用消息的 MessageId 属性来实现，该属性将在尝试传递时保持不变。

【讨论】：

感谢您的回复。这些信息很有用，但我想我的问题可能措辞不佳。我会把这个问题做得更好。

【解决方案5】：

如果由于崩溃或其他异常终止（实例重启等）而不再有任何进程读取或写入队列，该队列是否有效地孤立了？

没有队列允许通过代理消息进行通信，如果您的所有应用程序由于某种原因而死，那么队列仍然存在并且当它们再次活跃时将在那里，它是松散解耦应用程序的通信通道。关于计费 “消息根据在计费月份发送到服务总线或由服务总线传递的消息数量收费”，如果存在队列但没有人使用它，则不会向您收费。

我通过创建几个队列来测试这一点，然后终止应用程序。那些队列还在机器上很久了稍后。

队列的全部意义在于保证松散解耦的应用程序的消息传递。将队列想象成一个实体或应用程序，它本身具有高可用性 (SLA)，因为它托管在 Azure 中，您的生产者/消费者可能会死亡/重新启动，并且队列将在 Azure 中处于活动状态。 *注意我对你的措辞有点困惑：“很久以后仍然在机器上”，队列实际上并不存在于你的机器上，它位于 Azure 中指定的服务总线命名空间中。您可以通过我在上一个答案中指出的工具查看和管理队列。

我们如何检测和删除这些队列，因为它们将计入 Azure 限制等。

如上所述，默认的最大队列数为 10,000（每个服务命名空间，这可以通过支持呼叫增加），队列管理可以通过另一个答案中所述的工具来完成。只有当您不再有生产者/消费者希望写入队列时（即再也不会），您才应该考虑删除队列。你当然可以通过 namespaceManager.QueueExists 在你的生产者/消费者应用程序中创建和删除队列，更多信息在这里How to Use Service Bus Queues

如果它有助于使问题更清晰，这是一种独特的情况，其中队列具有特殊名称，并且在有限的时间内，发布者 (1) 和订阅者 (1) 的集合非常有限。

听起来您需要使用主题和订阅How to Use Service Bus Topics/Subscriptions，此链接还有一个关于“如何删除主题和订阅”的部分如果您的生命周期非常有限，那么您可以在应用程序中处理主题创建/删除否则你可以有一个单独的队列/主题/订阅设置/删除脚本来处理这个逻辑......

【讨论】：

没有人知道我在这里问什么。当我说“仍在机器上”时，我的意思是云中的队列仍然存在，这是非常不可取的。这个问题的重点是我们有一个非常具体的专有情况，我们希望每个 Web 角色都有一个专用队列。 Web 角色将是订阅者，在运行时，它将告诉各种工作进程将该通道用作响应队列。如果该 Web 实例崩溃，或者被 Fabric 控制器重新启动，或者其他任何事情，该队列将被孤立。我们如何清理它？
队列将成为孤立的原因是因为它是特定于 web-role-instance 的，并且如果 web 角色实例死亡或重新启动，则该队列将不再有发布者或订阅者。但是，根据我的直接观察，这会导致队列在服务总线上保持活动状态。我知道我不会被指控，而且我的问题没有提到任何关于指控的内容。我的问题提到了限制。如果我们使用主题/订阅，则会出现同样的问题。如果订阅者（网络角色）死亡，订阅将成为孤立的，因为它是特定于实例的。