azure - 在 Azure 服务总线上正确自动更新锁

标签 azure azureservicebus

所以我试图了解服务总线时序......尤其是锁的工作原理。人们可以选择手动调用 CompleteAsync,这就是我们正在做的事情。处理也可能需要一些时间。在这些情况下,我们要确保不会出现不必要的情况 MessageLockLostException .

似乎有几个数字可以关联:

  • 锁定持续时间(在总线上的 Azure 门户中找到,当前设置为 1 分钟,这是默认设置)
  • AutoRenewTimeout(OnMessageOptions 上的属性,当前设置为 1 分钟)
  • AutoComplete(OnMessageOptions 上的属性,当前设置为 false)

假设处理运行大约 2 分钟,然后要么成功,要么崩溃(目前哪种情况都没关系)。假设这是正常情况,因此这意味着每条消息的处理大约需要 2 分钟。

而且,它确实是一个队列而不是一个主题。我们只有一个消费者异步处理 MaxConcurrentCalls 的消息。设置为 100。我们使用 OnMessageAsyncReceiveMode.PeekLock .

作为单个消费者,我现在应该如何设置才能稳健地处理所有消息?

我认为将锁定持续时间保留为 1 分钟就可以了,因为这是默认值,为了安全起见,将我的 AutoRenewTimeout 设置为 5 分钟,因为据我所知,这个值应该是处理所需的最长时间一条消息( atleast according to this answer )。性能对于这个系统来说并不重要,所以我产生了共鸣,因为将消息锁定一些不必要的 1、2 或 3 分钟并不是邪恶的,只要我们没有得到 LockedException,因为这些没有提供任何实际值(value)。 p>

This threadthis thread给出了如何手动更新锁的很好的例子,但我认为有一种方法可以自动更新锁。

最佳答案

What should my settings now be as a single consumer to robustly process all messages?

除了 LockDurationMaxConcurrentCallsAutoRenewTimeoutAutoComplete 之外,还有一些 Azure 服务总线配置您可能想了解的客户。例如,不要创建将 MaxConcurrentCalls 设置为 100 的单个客户端,而是创建几个客户端,并在客户端之间分配总并发级别。请注意,您需要使用不同 MessagingFactory 实例来创建这些客户端,以确保您有多个“管道”来接收消息。即便如此,横向扩展并拥有竞争性消费者比让单个消费者处理所有负载要好得多。

现在回到设置。如果您的正常处理时间为 2 分钟,最好将实体上的 MaxLockDuration 设置为此时间而不是 1 分钟。这将消除对代理的不必要的锁定扩展调用,并消除 MessageLockLostException

此外,请记住,AutoRenewTimeout 是基于客户端的操作,而不是代理,因此无法保证。即使 AutoRenewTimeout 时间尚未过去,您也会遇到锁定丢失的情况。

AutoRenewTimeout 应始终设置为长于 MaxLockDuration,因为让它们相等会适得其反。让它比 MaxLockDuration 稍大一些,因为这是客户端的“保险”,当处理时间超过 MaxLockDuration 时,消息锁定不会丢失。从本质上讲,让这两个相等就禁用了这种后备。

关于azure - 在 Azure 服务总线上正确自动更新锁,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48443052/

相关文章:

json - 通过 powershell 将消息发布到 MS Teams

azure - 从现有 VHD 创建 Azure VM,无需使用 powershell

azure - 构建管道成功后,适用于Docker镜像的Azure发布管道

azure - 拒绝访问 azure 上的特定文件夹

Azure 应用服务部署 - 无法覆盖 appsettings.json

azure - 监控azure服务总线队列长度

c# - Azure 服务总线 - 只有一个订阅者接收消息

azure - 如何在 Azure 上为匿名 HTTP API 消息创建代理?

c# - Azure服务总线: ignoring messages sent by me