如何为RedLockFactory.CreateLockAsync()的expiryTime参数选择合适取值？

关于expiryTime的常见认知误区 #

你观察到「设置很小的expiryTime也能长期持有锁直到主动调用Dispose释放」，是RedLock.net内置的自动锁续期机制导致的，不代表这个参数没有实际作用：
库默认会在锁剩余有效期达到expiryTime的1/2时，自动向所有Redis节点发送续期请求，只要你的应用进程正常运行、和Redis的网络通信正常，锁就会被持续续期，不会因为初始设置的expiryTime到期而释放。

expiryTime的核心作用 #

这个参数本质是故障兜底机制，只有在异常场景下才会生效：

• 如果你的应用进程持有锁时突然崩溃、或者和Redis集群的网络长时间断连，自动续期操作就会失败，Redis上的锁会在expiryTime到期后自动释放，避免锁永久残留导致的死锁问题。
• 同时它也决定了自动续期的频率：expiryTime越小，续期请求发送的频率越高，会额外增加Redis的请求压力，极端场景下甚至会因为网络抖动导致续期不及时，锁提前过期。
  你测试时设置expiryTime为0无法获取锁是预期行为：Redis不支持过期时间为0的锁，相当于获取锁的同时就直接过期，自然会返回获取失败。

正确取值规则 #

你可以参考以下规则选择取值：

• 最小值必须大于你持有锁期间执行业务逻辑的最大预期耗时，同时叠加Redis集群的平均网络延迟，避免业务还没执行完成、首次续期还没发起，锁就已经到期释放。
• 常规业务场景推荐设置为10s~60s区间的取值，多数示例用30s是通用的工程最佳实践：既不会因为取值太小导致续期请求过于频繁，也不会因为取值太大，导致进程故障后锁残留太久，影响其他节点获取锁。
• 如果你的业务逻辑本身是分钟级的长耗时任务，可以适当将取值调整到1min~5min，不建议设置更长的时间：异常场景下锁残留过久会严重影响业务可用性。

内容的提问来源于stack exchange，提问作者RM.