针对你的场景，我来一步步拆解怎么配置才能避免MessageLockLostException，同时确认自动续锁的支持情况：

1. 自动续锁的支持确认 #

完全没问题！Azure Service Bus SDK的OnMessageAsync配合OnMessageOptions里的AutoRenewTimeout参数，就是专门为长时消息处理设计的自动续锁机制。它会在当前锁过期前自动向Service Bus发送续锁请求，只要这个超时值覆盖你的最大消息处理时长，就能确保处理期间锁不会失效。

2. 推荐配置方案 #

结合你的需求（处理时长约2分钟，优先避免锁异常，性能要求不高），调整以下配置即可：

• 保留锁时长1分钟：这个默认值不用改，自动续锁会周期性延长锁的有效期，短锁时长反而能在异常场景下更快释放消息给其他消费者（不过你是单消费者，影响不大）。
• 设置AutoRenewTimeout = 5分钟：你这个思路非常正确，这个值必须大于等于最大消息处理时长，留2-3倍的安全余量（比如5分钟）能完美覆盖偶尔的处理延迟或网络波动，彻底避免锁丢失。
• 保持AutoComplete = false：因为你是手动调用CompleteAsync，这个配置是正确的，确保只有当消息处理成功后才标记为完成，避免未处理完的消息被误标记。
• MaxConcurrentCalls = 100：如果你的单消费者实例资源（CPU、内存、网络）能支撑100个并发的2分钟任务，这个值可以保留；如果担心资源过载，也可以适当调低，比如20或50，毕竟你对性能要求不高，稳优先。

3. 额外注意事项 #

• 自动续锁依赖稳定的网络连接：如果你的应用和Service Bus之间的连接中断，续锁会失败，此时会触发MessageLockLostException。这种情况属于异常场景，建议你配置死信队列（DLQ），将处理失败的消息转入DLQ，方便后续排查。
• 手动续锁不是必需的：虽然SDK提供RenewLockAsync方法允许手动续锁，但自动续锁已经能满足你的需求，没必要额外写代码手动处理，增加复杂度。
• 确保CompleteAsync调用时机：一定要在消息处理完全成功后再调用CompleteAsync，不要提前调用，否则会导致未处理完的消息被移除队列。

内容的提问来源于stack exchange，提问作者Jim Aho