这篇文章主要介绍了Redis分布式锁如何设置超时时间，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
目录
- Redis分布式锁设置超时时间
- 网络抖动
- Redis宕机
- Redis分布式锁的超时问题
Redis分布式锁设置超时时间
Redis分布式锁主要依靠Redis服务来完成，我们的应用程序其实是Redis节点的客户端，一旦客户端没有释放锁，服务端就会一直持有这个锁，其他进程中的线程就无法获取到这把锁，于是就会发生锁死的情况。
所以我们在使用Redis分布式锁的时候，务必要设置锁的过期时间。
主要基于下面两点：
网络抖动
客户端A中的一个线程获取到了锁，然后执行finally中的释放锁的代码时，这时候网络出问题了，导致客户端A没有成功释放锁。此时对于redis服务端来说，它会一直把锁给客户端A，这样的话其他客户端自然也就不能获取到这个锁。
如果是设置了过期时间的话，即使客户端和服务端的网络不通了，服务端依然在进行时间的计算，时间到了直接把锁释放掉，等网络通了，不影响其他客户端获取锁。
Redis宕机
客户端A获取到了锁，Redis服务器突然宕机，锁没有释放。等到Redis再次恢复的时候，Redis服务端还会把锁给到客户端A，这样也会发生锁死的情况。
如果是设置了过期时间的话，服务器恢复后就会继续倒计时，时间到了服务器自动把锁释放，其他客户端也就可以尝试去获取锁了。
Redis分布式锁的超时问题
Redis的分布式锁并不能解决超时问题，如果在加锁和释放锁之间的逻辑执行得太长，以至于超出了锁的超时限制，就会出现问题，因为这时候第一个线程持有的锁过期了，临界区的逻辑还没有执行完，而同时第二个线程就提前持有了这把锁，导致临界区代码不能得到严格串行执行。
为了避免这个问题，分布式锁不要用于较长时间的任务，如果真的偶尔出现了问题，造成的数据小错乱，可能需要人工介入解决。
有一个稍微安全一点的方案，是将set指令的value参数设置为一个随机数，释放锁时先匹配随机数是否一致，然后在删除key，这是为了确保当前线程占有的锁不会被其他线程释放，除非这个锁是自动超时，但是匹配value,和删除ke y不是一个原子操作，所以只是相对安全。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持北冥有鱼。
