如果由于崩溃或其他异常终止（实例重启等），不再有任何发布者或订阅者读取或写入队列，主题或订阅，那么队列/主题/订阅是否有效孤立？
我通过创建一些队列来测试它，然后终止应用程序 . 这些队列很久以后仍然在服务总线上 . 似乎他们将永远呆在那里 . 如果我们想要这种行为，那将是美妙的，但在这种情况下，我们不这样做 .
我们如何检测和删除这些队列，主题和订阅？它们将计入Azure限制等，每次重新启动/修补/崩溃实例时，我们都不能拥有这些孤立的进程 .
If it helps make the question clearer, this is a unique situation in which the Queues/Topics/Subscriptions have special names, or special Filters, and a very limited set of publishers (1) and subscribers (1) for a limited time. This is not a case where we want survivability. These are instance-specific response channels. Whether we use Queues or Subscriptions is immaterial. If the instance is gone, so is the need for that Queue (or Subscription).
这是解决方案的一部分，其中每个Web角色都有一个专门的响应通道，可以监控它 . 在任何时候，此Web角色可能有许多通过其他消息传递通道（队列/主题）挂起的请求，并且它正在等待多个线程上的答案 . 我们需要响应返回放置消息的线程，以便Web角色可以响应调用者 . 在这种情况下，仅仅拥有基于机器的订阅是不利的，因为它将接收其他线程的消息 . 我们需要每个发布线程 Build 一个专用的响应通道，因此该通道上唯一的东西就是该线程的响应 .
即使我们使用Subscriptions（使用某种与实例相关的过滤器）对Subscription进行长轮询接收操作，如果Web角色实例死亡，该Subscription将被孤立，是否正确？
这个问题可以像这样简化：如果队列/主题/订阅没有更多的发布者或订阅者，那么该服务实际上是孤立的 . 如何检测和清理这些孤儿？
5 回答
在这种情况下，您正在寻找队列/订阅本质上是"dynamic" . 它们将基于使用而创建和删除，而不是针对这些实体的当前显式供应模型 . Service Bus为您提供了执行创建/删除操作的API，因此您可以适当地插入OnStart / OnStop角色事件 . 如果这些操作由于某种原因失败，则孤立实体将存在 . 您可以再次根据实体名称的唯一标识符对它们执行清理操作 . 这方面的一个例子可以在这里看到：http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/
在不久的将来，我们将为Queues / Topics / Subscriptions添加更多元数据和查询功能，以便您可以查看上次访问它们的时间并做出清理决策 .
服务总线队列使用“代理消息传递”基础结构构建，该基础结构旨在集成可能跨越多个通信协议，数据协定，信任域和/或网络环境的应用程序或应用程序组件 . 允许机制与持久消息传递可靠地通信 .
如果客户端（发布者）将消息发送到服务总线队列然后崩溃，则消息将存储在队列中，直到消费者从队列中读取消息为止 . 此外，如果您的消费者死亡并重新启动它将只轮询队列并获取正在等待它的任何工作（您可以扩展并让多个消费者从队列中读取以提高吞吐量），Service Bus Queues允许您通过以下方式解耦您的应用程序耐用的 Cloud 网关，类似于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（每个服务命名空间，这可以通过支持调用增加）
正如Abhishek Lai所说，没有支持孤儿检测功能 .
孤立检测可以通过多种方式在外部实现 . 例如，无论何时发送/接收消息，都要更新SQL数据库中的时间戳，以指示queue / tropic / subscription仍处于活动状态 . 然后可以使用此时间戳来确定孤儿 .
如果您的进程很可能崩溃，则队列中的邮件传递会出现问题，但队列仍可用于处理您的请求 . 使用Windows Azure Service Bus处理应用程序崩溃和不可读消息here：
Service Bus提供的功能可帮助您从应用程序中的错误中正常恢复，或者难以处理消息 . 如果接收方应用程序无法处理该消息出于某种原因，它可以在收到的消息上调用Abandon方法（而不是Complete方法） . 这将使服务总线解锁队列中的消息，并使其可用于由同一消费应用程序或其他消费应用程序再次接收 .
如果应用程序在处理完消息之后但在发出完成请求之前崩溃，则在重新启动时将重新传送消息给应用程序 . 这通常称为至少一次处理，即，每个消息将被处理至少一次，但在某些情况下，可以重新传递相同的消息 . 如果方案不能容忍重复处理，那么应用程序开发人员应该向其应用程序添加其他逻辑以处理重复的消息传递 . 这通常使用消息的MessageId属性来实现，该属性在传递尝试中保持不变 .
没有队列允许通过Brokered Messages进行通信，如果所有应用程序因某种原因而死亡，那么队列仍然存在并且当它们再次变为活动时将存在，它是松散分离的应用程序的通信通道 . 关注账单“消息是根据在结算月份期间发送给服务总线或由服务总线发送的消息数量收费”如果队列存在但没有人使用它，则不会向您收取费用 .
队列的重点是保证松散分离的应用程序的消息传递 . 将队列视为一个实体或应用程序本身具有高可用性（SLA）作为其托管在Azure中，您的 生产环境 者/消费者可以死/重新启动并且队列将在Azure中处于活动状态 . *注意我对你的措辞有点困惑：“很长一段时间后仍在机器上”，队列实际上不在您的机器上，它在Azure中位于指定的服务总线命名空间中 . 您可以通过我在上一个答案中指出的工具查看和管理队列 .
如上所述，默认的最大队列数是10,000（每个服务命名空间，这可以通过支持调用增加），队列管理可以通过另一个答案中陈述的工具完成 . 当您不再有 生产环境 者/消费者想要写入队列时（即从不再次），您应该只想删除队列 . 您当然可以通过namespaceManager.QueueExists在 生产环境 者/消费者应用程序中创建和删除队列，这里有更多信息How to Use Service Bus Queues
听起来你需要使用主题和订阅How to Use Service Bus Topics/Subscriptions，此链接还有一个关于'How to Delete Topics and Subscriptions'的部分如果您的生命周期非常有限，那么您可以在应用程序中处理主题创建/删除，否则您可能有一个单独的队列/主题/订阅设置/删除脚本来处理这个逻辑......