我想知道是否可以将中转消息发送到消息已处于延迟状态的队列/主题？
我问这个是因为我目前有一个执行以下操作的过程......
- 进程启动并将中转消息发送到队列(这会触发一个函数，该函数将消息正文记录为表存储中具有"正在处理"状态的实体(。
- 在此过程中完成其他工作
- 如果我们在流程结束时没有任何问题，则会将另一条中转消息与完成消息一起发送到队列(这将触发以"完成"状态更新表存储中的实体的相同函数(。
虽然这种方法大部分有效，但它感觉笨重和脆弱。 我真的希望能够向队列发送消息，然后让最后一步使消息在队列中可见，以便函数(持久函数(可以使用它。
我想过设置ScheduledEnqueueTimeUtc，但我不能保证该过程何时完成(我在这里考虑最坏的情况(，所以我不确定设置多长时间。
我还查看了BrokeredMessage的Defer选项，但似乎这只能从接收器设置，并且最初不能处于延迟状态。
我尝试使用服务总线代理消息执行的操作是否可行？我可以将计划的排队时间设置为相当长的时间(例如 2 小时(，如果达到该时间，它会自动过期并移动到死信队列吗？ 我是否应该将初始消息发送到死信队列，然后在该过程完成后检索并重新提交？
有没有人有过实施这样的过程的经验......发送启动消息并仅在收到完成通知后处理消息？ 我需要它尽可能强大，因为我在这个过程中处理金融交易。
希望我的解释是有道理的。
我想知道是否可以将中转消息发送到消息已处于延迟状态的队列/主题？
那是不可能的。您只能延迟一条全新的消息，而不能延迟它。延迟需要首先接收消息才能SequenceNumber。
使用ScheduledEnqueueTimeUtc有其挑战，因为您将来将发送它，但一旦处理结束就无法取消。相反，您可以利用立即返回SequenceNumberQueueClient.ScheduleMessageAsync()。这样，您可以将消息设置为遥远的未来，但如果处理提前完成，也可以取消它。
我最终通过保留发送两条消息的过程来解决此问题，但重构了我的持久函数以Table Storage中记录消息，检查是否已收到两条消息，如果有，则向Azure Queue Storage添加新消息。 第二个函数侦听启动其进程的队列。
经过大量测试，这似乎是一个非常强大的解决方案。 然后，两条消息到达的顺序或需要多长时间并不重要......只要他们两个都到了，那就是第二个功能开始的时候。