Azure Service Bus主题，包含一些即时订阅和一些延迟订阅
我想在一个主题上放一个BrokeredMessage。有些订阅者必须立即处理。一个或多个订阅服务器必须在第二天才开始处理。
我曾经研究过使用BrokeredMessage.ScheduleDenQueueTimeUTC属性来延迟队列和主题上的消息处理，但这意味着所有订阅者都将延迟它们的处理。
我的想法是，我应该在不延迟入队时间的情况下将BrokeredMessage添加到主题中，并在一个订阅服务器上创建一个函数，该函数使用延迟的入队时间创建一个新的BrokeredMessage，然后将其添加到另一个队列中。
这似乎是矫枉过正。是我疯了，还是有其他方法可以推迟对其中一个主题订阅的处理？
共有1个答案
您可以将具有不同ScheduledEnqueueTimeUTC的重复消息发布到主题。
订阅应该为其配置规则。
所有重复的消息都应具有不同的自定义属性集，以便根据规则将消息发送到适当的订阅。有关规则的更多细节，请参阅此处。
-
我有几个。Net 5.0微服务，RabbitMQ作为消息代理。现在我正在切换到AWS SQS。很少有服务在侦听相同的消息（这是通过RabbitMQ中的Exchange完成的）。在AWS中，这可以通过将SQS队列订阅到SNS主题来实现。我创建了SNS fifo topic和SQS fifo队列，将这些队列订阅到topic。当我将消息直接发布到队列时，一切都会立即工作，但当我将消息发布到SNS主题时，
-
我试图理解延迟和延迟订阅操作符之间的区别。 本文件描述了延迟操作员： 延迟操作符通过在发出每个源可观察项之前暂停特定的时间增量（您指定）来修改其源可观察项。这会将可观测项发出的整个项目序列在时间上向前移动指定的增量 delaySubscription是这样描述的： 还有一个操作符，您可以使用它延迟对源可观察对象的订阅：delaySubscription。 然而，当我测试这两个操作员的行为时，我觉得
-
https://github.com/azure/azure-service-bus/tree/master/samples/dotnet/gettingstart/microsoft.azure.servicebus/topicsubscriptionwithruleoperationssample 现在我想添加一个筛选器/规则，这样只有通过筛选器中定义的特定条件的消息才应该给订阅。 例如,下面
-
客户对主题的订阅（即订阅者）的寿命是多少？ 我之所以这么担心，是因为我认为服务总线的一个特点--持久的信息。因此，我认为在连接不稳定的情况下，可以保证提供持久的消息。 那么，当一个应用程序（多个应用程序中的一个）失去与服务总线的连接一天，然后第二天重新启动应用程序并实例化一个新的订阅客户端实例时，会发生什么呢？当其他应用程序由于自己的订阅已经处理了这些相同的消息时，应用程序是否会继续接收等待传递的
-
我正在试验消息驱动Beans，以便从外部ActiveMQ实例接收主题订阅消息。 我的测试首先从队列订阅开始，它工作得很好。 然后我想尝试主题订阅，但我无法让它工作。 这就是我所拥有的： 会议记录。xml 这是MDB： 我不知道为什么，但从日志中我可以看到，TomEE创建了一个队列，而不是一个主题： 另一个证明是，当我添加持续时间配置时，服务器不会启动： 然后服务器抱怨这不适合配置类型javax.j
-
物联网有很多设备，通过订阅设备的topic可以监听物联网设备接收到的消息。 请求方式： "|4|1|2|topic|\r" 参数： topic 设置订阅的topic,获取设备topic可参考教程 返回值： "|4|1|2|1|\r" 订阅成功 "|4|1|2|2|1|\r" topic订阅达到上限(一个OBLOQ最多订阅5个topic)，订阅失败 "|4|1|2|2|2|\r" topic订阅失败