客户订阅（即订阅者）某个主题的生命周期是多少？

Question

客户订阅（即订阅者）主题的生命周期是多久？

条件

在我的开发环境中，我一直在为各种服务总线主题创建 SubscriptionClient 实例。

我担心，对于我为给定主题实例化的每个订阅客户端，我可能会无意中复制发出的消息（每次订阅给定主题时）。

我的理论

我担心的原因是我认为服务总线的特性之一，即持久消息。因此，我认为在连接不稳定的情况下可以保证传递持久消息。

那么，如果一个应用程序（多个应用程序中的一个）在一天内失去与服务总线的连接，然后在第二天重新启动该应用程序并实例化一个新的订阅客户端实例，会发生什么情况？当其他应用由于自己的订阅而已经处理了相同的消息时，该应用是否会继续接收等待发送的消息？

总之，客户订阅（即订阅者）某个主题的生命周期是多少？

附录

参考资料：

Auto-expire orphaned Subscription (Azure ServiceBus Messaging SubscriptionClient)

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements

https://weblogs.asp.net/sfeldman/asb-subs-with-correlation-filters

Answer 1

客户订阅（即订阅者）某个主题的生命周期是多久？

一个有点宽泛的问题。如果您指的是连接到代理的客户端，只要存在不间断的底层连接，客户端就会连接到订阅。如果您指的是逻辑订阅者，则只要逻辑订阅者连接。这可能是 24/7/365 或偶尔。然后，该生命周期由您的系统将要执行的任何操作来定义。

那么，如果一个应用程序（多个应用程序中的一个）在一天内失去与服务总线的连接，然后在第二天重新启动该应用程序并实例化一个新的订阅客户端实例，会发生什么情况？

新的客户端实例仍然是您的逻辑订阅者的实例，对吗？只要是这种情况，您就会收到该订阅者的事件。重要的是要注意新的客户端实例应该连接到同一个订阅，而不是尝试创建一个新的订阅。如果是这样，那么您肯定会有重复。

当其他应用由于自己的订阅而已经处理了这些相同的消息时，该应用是否会继续接收等待传递的消息？

如果您运行多个连接到同一主题的应用程序实例，如果其中一个出现故障，其余的将继续处理消息。不会有待处理的消息。如果您有其他应用程序使用来自不同主题的消息，那么是的，您的重新连接应用程序将接收在它关闭时发布的所有消息。

您可能想查看Competing Consumers 模式。订阅是具有竞争消费者的队列。