我希望使用Azure Service Bus支持的NServiceBus实现一个简单的pub-sub演示。
我正在使用不确定数量的订阅者，因为各种情况会产生更多的订阅者或现有的订阅者，所以每次创建订阅者时，我都会创建Endpoint和EndpointInstance一个独特的名称，并订阅我感兴趣的活动。
当订阅者关闭时，我取消订阅活动并停止EndpointInstance。
但是，如果我检查我的服务总线，则不会清除在此过程中创建的队列和主题订阅。这意味着经过一段时间后，由于我生成EndpointInstance名称的方式，我可能会有数百个队列和主题订阅永远不会再次使用。
我该如何清理它们？
我错过了什么吗？我不应该为每个订阅者创建一个新的Endpoint和EndpointInstance（这似乎是官方样本和指南中使用的模式）。
更新：
刚刚想到的类比就像推送通知系统，其中客户（订户）上线并订阅总线。发布活动时，我希望所有在线客户端都能收到它。当客户端关闭时，我不关心发送的消息，而不是我有兴趣在客户端上线时收到任何丢失的消息。我想关闭订阅并清理底层基础架构（队列，订阅等）。
在我的场景中，每个客户端都将定义自己唯一的Endpoint和Endpoint实例。逻辑端点如何在此时发挥作用？
答案 0 :(得分：3)
您所描述的情景很有意义。您对创建的临时端点感兴趣，为其目的服务，然后从系统中删除。这些端点是唯一的，没有多个实例。即使他们这样做，所有情况都会被撕毁。
这意味着一段时间后，由于我生成EndpointInstance名称的方式，我可能会有数百个队列和主题订阅永远不会再次使用。
您在订阅时遇到的问题是一个错误。我提出了一个问题here: link。请插入以提供更多反馈。您希望看到的行为是在解决错误后应该发生的事情。即一旦您从某个特定事件中取消订阅，该事件就不应再转发到您的端点（如果是ForwardingTopology）或存储在端点的订阅下（如果是EndpointOrientedTopology）。
请注意，对于端点输入队列，当端点本身运行时，NSB无法移除队列。在端点被删除后，您必须自定义代码。
答案 1 :(得分：1)
您提到了pub / sub 演示，并且在端点被销毁后能够清理所有内容。您正确地取消订阅了您的端点，这意味着从Azure Service Bus中删除了订阅，并且已发布的消息不再到达队列。
在生产方案中，您可以出于各种原因关闭端点。其中之一是在数据存储区上部署新版本或执行维护。另一个可能就像您的服务器/服务崩溃等等一样简单。当它关闭时，在生产场景中，您希望消息仍然到达队列。这样，只要端点再次备份，您就可以可靠地处理它们。
由于这个原因，我们不支持清理队列。如果要在关闭端点后清理所有内容，则必须手动删除队列以及不需要的队列。
关于演示设置，您提到了唯一的端点和实例。为了清楚起见，让我试着解释一下我们对端点和实例的意义。您可以构建执行某些任务的逻辑端点。它可以包含各种处理程序，传奇等。它具有独特的名称和独特的功能。您可以在系统中拥有各种逻辑端点。
部署后，通常每个端点都有一个实例。如果要扩展，可以部署同一逻辑端点的另一个实例。使用Azure Service Bus时，您将拥有一个名为competing consumers的内容。这基本上意味着两个端点实例都试图从同一队列中检索消息。一个人总是赢得并开始处理消息。
将消息发布到同一端点的另一个实例是不合逻辑的，因为您永远无法确定（逻辑）端点的哪个实例将获取该消息。您仍然可以订阅自己的消息，但逻辑端点会订阅自己的消息。不要针对特定情况这样做，这是不可能的。
然而， 可以发布由其他逻辑端点接收的消息。无论他们有多少实例。现在让我感到困惑的是你的下一个陈述：
我正在与不确定数量的订阅者合作，其中包括更多的订阅者或根据各种条件杀死的现有订阅者
您似乎正在动态创建新的逻辑端点并部署这些端点。 可以根据配置为其提供唯一的名称，在部署时设置。但是我仍然不明白你为什么要演示这个。
如果这有帮助，请告诉我，如果没有，请在此帖后面发表评论，我会尝试回答更多问题。也许在这篇文章中作为更新，因为评论在你可以使用的字符数量上非常有限。
答案 2 :(得分：0)
你有什么样的订阅者？是应该所有客户收到相同类型的事件还是要过滤它们？如果最后它更像是通知。
我怀疑您有一些客户端连接到您的系统一段时间，并且只对专门针对该客户端的事件感兴趣。
像SignalR这样的框架非常适合您希望将通知发送回特定客户端的用例。
但是，在您的系统中，您可以使用NServiceBus在您自己的端点之间进行通信，这可以触发应该作为通知推送到正确客户端的事件。