Microsoft的服务总线是否为主题中的每个订阅复制消息？
例如，假设有一个具有五个订阅者的单个主题，那么该消息是存储在服务总线的数据库中五次--每个订阅者一次--还是该消息仅存储一次，并使用业务逻辑来确定哪些订阅者已经读取了该消息？
如果有一个正式的站点和/或文档提供作为参考就好了。
共有1个答案
Azure服务总线的行为似乎是为每个订阅者保留一个副本。我通过创建一个包含两个订阅的主题来测试这一点。我发送了一条消息，看到主题的字节大小是464（使用Topic.sizeinbytes）。当我收到一条订阅消息时，大小下降一半到232。我用三个订阅对它进行了测试，结果出现了相同的行为：696字节。
即使他们没有为每个订阅保留消息的副本，他们也会计算消息的大小乘以订阅的数量，然后计算主题的最大大小，这可能就是您要确定的。
我同意，如果他们记录了这些行为，特别是Windows Server的服务总线，那将会影响您需要预留的存储量的规划。至于Azure Service Bus端，我不确定幕后实现的重要性，不知道它是如何影响主题的最大大小的。
-
有可能做到这一点吗？
-
我之所以要这样做，是因为我们的服务在部署时配置订阅规则，并且具有消息代理的服务可能会在具有订阅客户端的服务更改规则集和新的业务逻辑之前部署该服务，该服务会发送一组新的消息。我们不希望丢失在部署期间发送的消息，并在新服务退出时处理它们。 干杯。
-
我想将一个小的JSON消息放入中。消息将具有附加到它的“ProviderID”属性，并且根据筛选规则，该消息将被筛选到特定于提供程序的上 但是，我似乎无法在上指定共享访问策略，以限制第三方提供商仅连接到他们自己的 我假设应该在订阅上设置以便将这些消息发送到另一个并在那里应用特定于提供程序的安全性，这样做是否正确。 或者有其他/更好的/推荐的方法来做这件事。
-
我试图遵循Mark Heath的控制台应用程序示例，使用筛选后的订阅检索服务总线主题消息。但是，我实际上无法检索实际筛选的消息(Filtered1、Filtered2)。消息确实会被使用，但我无法查看它们，因为代码从未像处理非过滤消息（AllMessages）那样进入回调函数。对我错过了什么有什么想法吗？ 发件人代码 接收机代码
-
这似乎是最简单的解决办法。让我们看看流程： 第三方向RESTful API发送请求，以获取Windows Azure服务总线连接字符串-凭据-。 一旦拥有连接字符串，第三方就会连接到Windows服务总线，并开始从某个主题订阅接收消息。注意：连接字符串是在服务器端加密的，只能由接受的客户端解密。 优点 null null 第三方请求一个类似于RESTful的TCP API，以便订阅一些Window