分布式系统----分布式锁

分布式锁

当系统中某一个资源不能让多个服务同时操作的时候，就需要用到分布式锁对当前资源进行设置，常见的分布式锁实现方案有：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 实例，然后执行如下步骤获取一把锁：

1. 获取当前时间，单位为毫秒
2. 跟上面类似，轮流尝试在每个master节点创建锁，过期时间较短，一般也就几十毫秒
3. 尝试在大多数节点上建立一个锁，比如5哥节点就要求是3个节点(n/2 + 1)
4. 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了
5. 要是锁建立失败了，那么就依次删除这个锁
6. 只要别人建立一把分布式锁，就得不断轮询去尝试获取锁

Zookeeper 分布式锁

zk分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时的znode,此时创建成功，就获取了这个锁，这个时候别的客户端来创建锁就会失败，只能注册个监听器监听这个锁，一旦释放锁就是删除掉这个znode，一但释放掉就会通知客户端，然后有一个等待着的客户端就可以重新加锁

Redis分布式锁和zk分布式锁的对比

redis分布式锁，其实需要自己在不断尝试获取锁，比较消耗性能
zk分布式锁，获取不到锁，注册一个监听器即可，不需要不断主动尝试获取锁，性能开销较小
另外一点就是，如果redis获取锁的那个客户端BUG或者挂了，那么只能等待超时时间之后才能释放锁，而如果ZK的话，因为创建的是临时的znode，只要客户端挂了，那么znode就没了，此时就自动释放锁

ZK分布式锁相对于Redis更牢靠，并且模型简单易用

项目中 zk 一般使用临时顺序性锁来实现分布式锁