我正在尝试使用Azure Service Bus编写Message Dispatcher模式。基本思想是我有许多客户端与中央服务器保持TCP连接。
我希望能够做的是在服务总线主题上发布消息，然后由该中央服务器使用，然后发送到相应的客户端。我认为解决这个问题的正确方法是使每个客户端的语义等效于一个队列，这将特别有用，因为客户端可以随意断开连接，并且消息应保留在队列中，直到它们重新连接。我希望对邮件传递有很强的保证，所以我认为Peek-Lock在这里效果最好（而不是接收和删除）。
我可以想到几种方法：
为每个客户端维护一个单独的队列。我认为这是一个过于重量级和天真的解决方案。
在中央服务器上启动n个订阅（其中n是客户端数量），当有新消息进入时，将其分派给相应的客户端。这还涉及检测客户端何时断开连接或无法访问，并且在重新连接之前不检查这些订阅。这可以工作，并且大量使用Task和Async应该能够很好地工作，但它似乎也很浪费。
客户端服务器只有一个主题订阅，但有一个SqlFilter，它只“侦听”当前连接的客户端的消息。这将涉及每次客户端连接/断开连接时更改过滤器，并检测到消息无法传递，因为客户端刚刚断开连接并将该消息留在队列中。
我认为最后一个解决方案在可扩展性方面可能是最好的解决方案：我仍然在编写这些示例，所以在我测试之前无法确定。有人对此有任何指导吗？
答案 0 :(得分：0)
上面第三个解决方案的问题是，如果您要在每次客户端断开连接时更新过滤器，那么当客户端断开连接时对客户端意味着的任何新消息都将被主题删除。根据您对问题的描述，您不希望这样。
因此，即使客户端断开连接，您也希望能够保留消息，因此您必须为每个客户端进行一次订阅。 （2以上）.. 如果确实有某些客户端可能会消失并且永远不会回来，那么您可以使用主题功能自动删除空闲的订阅..其中SERVICEBUS主题将垃圾收集未使用的订阅。
请注意，带有2的问题是我们只支持给定主题的2000个订阅。
第二个选项没有任何缺点..如果客户端断开连接，您可以停止接收订阅。
但是，您应该确保您未收到的订阅量不会增长太多。因为您不希望单个订阅因为您已停止使用而占用该主题的整个空间来自它的消息