【发布时间】：2021-11-13 10:44:30
【问题描述】：
我看到该会话用于确保对 azure 服务总线队列进行 FIFO 处理。但我想了解为什么默认不支持 FIFO（不使用会话密钥）。是因为1个单队列的并发消费者吗？
谢谢。
【问题讨论】：
标签： azureservicebus azure-servicebus-queues
【发布时间】：2021-11-13 10:44:30
【问题描述】：
在大多数情况下，即使没有会话，消息也会以 FIFO 方式接收，但在这种情况下无法保证。只有一个订阅者能够完全锁定它的分区是这里的关键。
如果举个例子，说明在没有会话的情况下如何乱序接收事物，这可能会更有意义。假设我们有两个接收者 A 和 B，从队列中的 2 条消息开始。
- A 拿起第一条消息。
- B 拿起第二条消息。
- 第三条消息被添加到队列中。
- A 未能正确处理消息，第一条消息返回到队列。它排在行尾，将在第三条消息之后发送。
- 恢复后，A 拿起第三条消息。
- B 完成第二条消息。它获取队列中的下一项，这实际上是发送的第一条消息。这两条消息现在乱序了。
对于会话，每条消息都将专门发送给 A 或 B，并且消息的顺序保持不变。
【讨论】：
-
谢谢萨马拉。对于第 4 点，您的情况是使用 peek-lock 还是接收和删除？因为我认为，如果 A 未能正确处理消息，它不会转到行尾，而是保持为 ?
-
无论进程成功还是失败，接收和删除都会将其从队列中删除。当由于锁过期或被显式返回而将消息返回到队列时，Service Bus 将其视为新消息，因此最终排在队列的后面并且出现乱序。使用接收删除您可能不会丢失 FIFO，但这仍然不能保证。使用分区，消息被显式地按顺序处理——也就是说，直到第一条消息在给定的分区中完成，第二条消息不可用，因此它能够保证 FIFO。
-
我明白了！我想知道您是否可以提供有关服务总线将过期消息视为新消息的部分的任何链接（因此放置在行尾）？提前致谢！
-
我可能需要回顾一下这个例子（我记得它是这样工作的，但我已经有一段时间没有测试过了。）它在本文中提到它会立即恢复它锁过期后：docs.microsoft.com/en-us/azure/service-bus-messaging/…。这个概念仍然适用。在等待该锁到期时，您可以处理任意数量的消息。
-
我明白了，这意味着它可能会在失败的消息锁定尚未到期的情况下处理其他消息，当应用程序备份时，对吧？您介意是否可以更新上面的答案，此后我将接受答案。谢谢！