分布式锁
当系统中某一个资源不能让多个服务同时操作的时候,就需要用到分布式锁对当前资源进行设置,常见的分布式锁实现方案有:redis 分布式锁,zookeeper分布式锁
Redis 分布式锁
官方叫做RedLock算法,是Redis官方支持的分布式锁算法
这个分布式锁有三个重要的考量点:互斥(只能有一个客户端获取锁),不能死锁,容错(大部分Redis节点或者这个锁就可以加可以释放)
实现方式
简单实现
Set my:lock 随机值 NX PX 30000,这个命令就可以,NX 的含义就是只有当key不存在的时候才会设置成功,PX 30000的意思是当30秒后悔自动释放,别人创建的时候如果发现已经有了就不能加锁
释放锁就是删除key,但是一般可以用LUA脚本进行删除,判断value一样可以删除
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
为什么要用随机值?
因为某个客户端获取到了锁,但是阻塞了很长的时间才执行完,此时可能已经自动释放锁了,此时可能别的客户端已经获取到了这个锁,要是这个时候直接删除key的话会有问题,所以得用随机值加上面的LUA脚本来释放锁
RedLock算法
这个场景假设有一个Redis cluster, 有5个redis master 实例,然后执行如下步骤获取一把锁:
- 获取当前时间,单位为毫秒
- 跟上面类似,轮流尝试在每个master节点创建锁,过期时间较短,一般也就几十毫秒
- 尝试在大多数节点上建立一个锁,比如5哥节点就要求是3个节点(n/2 + 1)
- 客户端计算建立好锁的时间,如果建立锁的时间小于超时时间,就算建立成功了
- 要是锁建立失败了,那么就依次删除这个锁
- 只要别人建立一把分布式锁,就得不断轮询去尝试获取锁
Zookeeper 分布式锁
zk分布式锁,其实可以做的比较简单,就是某个节点尝试创建临时的znode,此时创建成功,就获取了这个锁,这个时候别的客户端来创建锁就会失败,只能注册个监听器监听这个锁,一旦释放锁就是删除掉这个znode,一但释放掉就会通知客户端,然后有一个等待着的客户端就可以重新加锁
Redis分布式锁和zk分布式锁的对比
redis分布式锁,其实需要自己在不断尝试获取锁,比较消耗性能
zk分布式锁,获取不到锁,注册一个监听器即可,不需要不断主动尝试获取锁,性能开销较小
另外一点就是,如果redis获取锁的那个客户端BUG或者挂了,那么只能等待超时时间之后才能释放锁,而如果ZK的话,因为创建的是临时的znode,只要客户端挂了,那么znode就没了,此时就自动释放锁
ZK分布式锁相对于Redis更牢靠,并且模型简单易用
项目中 zk 一般使用临时顺序性锁来实现分布式锁