关于Redis分布式锁对思考


分布式锁是在分布式环境下对共享资源保护对一种手段,通过redis,我们可以实现分布式锁,但是其中挺多细节需要我们关注。

如果要实现分布式锁,最简单对思路是我们通过 set get del指令:

if(get lock == nil ){#1
	set lock foobar#2
	...dosomething#3
	del lock#4
}

上面的方法,很明显对问题 get 后 set 不是原子操作,两个线程同时操作时可能在第一步判断时通过走到第二步,等于这个资源没有被保护好,所以这样加锁对方式是错误的。
对于上面这种情况我们有一个解决办法 通过setnx,setnx的意思是不存在这个key则设置,否则操作失败。这个指令保证了get和set的原子性。基于setnx的操作如下:

if(setnx lock foobar){#1
	...dosomething#2
	del lock#3
}

但是这种办法就天衣无缝了吗? 显然不是。我们假想一下,如果上述过程进行到#2,但是机器宕机或者网络中断或者其他原因无法与redis通信并且正确执行#3。那么这个时候可能会导致这个锁一直得不到释放,而其他请求一直无法获取到这个资源造成死锁。生产环境这种情况绝对是不允许的。那么有什么更好的解决办法呢?
如果我们在setnx的时候能加个超时时间就好了,到了时间,不管有没有del操作,这个锁都会被释放掉,这样就能够解决死锁这一情况。redis提供了expire指令可以设置key的失效时间。改造后如下:

if(setnx lock foobar){#1
	expire lock 3000#2
	...dosomething#3
	del lock#4
}

很明显这个也存在和上面一样的问题,因为setnx和expire不是原子操作 ,那么#2还没执行到可能就宕机,网络中断等,那么就退化成上面一样的情况了。幸运的是redis对#1#2两个步骤也提供了原子操作的指令。
SET key value NX PX 30000
这样#1#2就合并成了一步:

if(set lock foobar nx px 3000){#1
	...dosomething#2
	del lock#3
}

感觉上已经比之前好了很多,但是这种方式仍然存在问题。因为失效时间是个很尴尬的事,如果客户端A在#2执行时间太长了,而key已经失效了,这个时候线程2就又能成功获取到锁,而此时客户端A再执行#3就会把线程B刚加的锁给释放掉,这个时候如果再来一个客户端C又能获取到锁,而后客户端B又可能将客户端C的锁给del掉,导致了一种错乱,同时锁也是不可用的。正对这种问题我们可以尝试在value中做点手脚。如果每次我们设置的value都是一个随机值,这个值由获取锁的线程生成,而在del key之前 我们获取这个值并与当前线程对比,如果相等,则说明这个锁是当前线程持有的,则进行del操作,如果不相等则可能是其他线程的锁,则不进行del,这样就不会误删其他线程的锁了:

random_value=random()
if(setnx lock random_value nx px 3000){#1
	...dosomething#2
	if(get lock == random_value){#3
		del lock#4
	}
}

上面的这个方法仍然存在缺陷,可以想象下下面这种情况:

  • 客户端1获取锁成功。
  • 客户端1访问共享资源。
  • 客户端1为了释放锁,先执行’GET’操作获取随机字符串的值。
  • 客户端1判断随机字符串的值,与预期的值相等。
  • 客户端1由于某个原因阻塞住了很长时间。
  • 过期时间到了,锁自动释放了。
  • 客户端2获取到了对应同一个资源的锁。
  • 客户端1从阻塞中恢复过来,执行DEL操纵,释放掉了客户端2持有的锁。

这种情况究其根本是 get 和 del 没有保持原子性,但是这次就没有那么幸运了,redis没有这样的原始指令给我们提供,但是我们可以通过lua脚本保持起原子性。

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

到此,redis单机版分布式锁的问题我们基本上就解决了。注意,我说的是单机版,对与集群情况下如果在master 加锁完成后 还没同步到slave节点,这个时候master突然宕机,导致slave变成了master节点,这个时候就会出现锁丢失的情况。这是个相当复杂的问题,这里就不做过多讨论了,有兴趣的同学可以参考 《基于Redis的分布式锁到底安全吗?》

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×