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