我在 Azure 的服务总线上有一个主题订阅，锁定持续时间为 30 秒并启用了会话。
我正在使用逻辑应用程序使用峰值锁定获取主题的消息，因为我关心处理消息的顺序。我想确保所有具有相同会话 id 的消息都按照它们添加到总线的顺序进行处理，即 FIFO。
下面是一个简单逻辑应用程序的屏幕截图，它在消息到达时触发（带有 5 秒轮询的 peek-lock），然后等待 15 秒才能完成消息。
当我在主题上加载 10 条消息时，逻辑应用程序的第一个实例会按您的预期触发并在大约 15 秒内完成，但是第二个逻辑应用程序不会在另外 15 秒内启动，即总共 30 秒后第一个逻辑应用程序启动（锁定持续时间的长度）。
我读过的所有内容都表明完成一条消息应该立即释放锁，但情况似乎并非如此。我做错了什么还是这就是它的工作方式？
我读过的所有内容都表明完成一条消息应该立即释放锁，但情况似乎并非如此。我做错了什么还是这就是它的工作方式？
LockDuration 指示一个队列（订阅毕竟是一个队列）保持消息对竞争消费者不可见，以确保当前处理节点可以在 LockDuration 定义的时间范围内处理它。如果需要，更新锁机制确保当前正在处理的消息上的锁被延长以允许比 LockDuration 更长的处理时间。需要记住的重要一点是，锁更新不能保证成功。
场景一：
但是，我尝试复制您的工作流程，将主题订阅锁定持续时间更改为 2 分钟（以查看 LockDuration 属性是否影响 LA 触发器）并手动提供 SessionID。下面是我的测试结果。
我已将前 10 条消息加载到主题中。
从上图中，您可以看到逻辑应用触发器的第二个实例在完成第一个实例后立即启动。
场景 2： 在这种情况下，我保持了相同的配置，但将 SessionId 更改为“ NextAvailable ”。现在，逻辑应用触发器等待整个锁定持续时间（2 分钟甚至更多时间）并触发下一个实例。
总之，如果您的消息具有相同的会话 ID 并在您的 LA UI 中将会话 ID 配置为“下一个可用”，那么它会在整个 LockDuration 时间范围内锁定消息。如果要避免这种情况，则需要在客户端“关闭队列中的会话”。这将立即释放锁并立即处理下一个实例。
当您关闭会话时，它假定上面没有更多消息，然后您将全部丢失。如何避免丢失消息并尽快处理它们而不等待锁定持续时间完成？我有一个会话接收器，下一个可用，我在收到消息后立即完成，然后关闭会话。同时，该会话的新消息到达，并且因为我关闭了会话，该消息丢失了。
