客户端(即订阅者(订阅主题的寿命是多少？
条件
在我的开发环境中，我一直在为各种服务总线主题创建订阅客户端实例。
我担心的是，对于我为给定主题实例化的每个订阅客户端，我可能会无意中复制出去的消息(每次我订阅给定主题时(。
我的理论
我担心的基础是由于我认为是服务总线的特征之一，即持久消息。因此，我认为在连接不稳定的情况下，可以保证传递持久消息。
那么，当一个应用程序(几个应用程序(失去与服务总线的连接一天，然后在第二天重新启动应用并实例化新的订阅客户端实例时，会发生什么情况？当其他应用由于自己的订阅而已处理这些相同的消息时，应用是否会恢复接收待传递的消息？
总之，客户(即订阅者(订阅主题的寿命是多少？
附录
引用：
自动过期孤立订阅(Azure 服务总线消息订阅客户端(
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements
https://weblogs.asp.net/sfeldman/asb-subs-with-correlation-filters
客户(即订阅者(订阅主题的寿命是多少？
这个问题有点宽泛。如果引用连接到代理的客户端，则只要存在不间断的基础连接，客户端就会连接到订阅。如果引用的是逻辑订阅者，则只要逻辑订阅者连接。可能是 24/7/365 或偶尔。然后，该生命周期由系统将要执行的任何操作来定义。
那么，当一个应用程序(几个应用程序(失去与服务总线的连接一天，然后在第二天重新启动应用并实例化新的订阅客户端实例时，会发生什么情况？
新的客户端实例仍然是逻辑订阅者的实例，对吗？只要是这种情况，您就会收到该订阅者的事件。请务必注意，新的客户端实例应连接到同一订阅，而不是尝试创建新订阅。如果是这样，那么您肯定会有重复项。
当其他应用由于自己的订阅而已处理这些相同的消息时，应用是否会恢复接收待传递的消息？
如果您运行连接到同一主题的多个应用程序实例，如果其中一个实例出现故障，其余实例将继续处理消息。不会有待处理的消息。如果您有其他应用程序使用来自不同主题的消息，那么是的，您的重新连接应用程序将接收在其关闭时发布的所有消息。
您可能需要查看竞争消费者模式。订阅是具有竞争使用者的队列。