[Java复习] 分布式锁 Zookeeper Redis

一般实现分布式锁都有哪些方式？

使用 Redis 如何设计分布式锁？使用 Zookeeper 来设计分布式锁可以吗？

这两种分布式锁的实现方式哪种效率比较高？

1. Zookeeper 都有哪些使用场景？

四大场景：

• 分布式协调
• 分布式锁
• 元数据/配置信息管理
• HA高可用性

分布式协调：

场景：A系统发请求到MQ，B系统消费之后，A系统怎么知道B系统的处理结果？

解决方案：用Zookeeper实现分布式系统之间协调工作。

A系统发请求之后，在Zookeeper上对某个节点的值注册监听器，一旦B系统处理完值后就修改Zookeeper的节点值，A系统就立马收到通知。

ZK分布式锁：

场景：对某一个数据需要2个修改操作，两台机器同时收到请求，但需要一台执行后另一台才能执行。

解决方案：使用ZK分布式锁。机器A收到请求后，在ZK创建一个znode，接着执行操作；

另外一个机器B也尝试创建znode，发现创建不了，注册这个锁的监听器，只能等待机器A执行完成之后再执行。

ZK 发现机器A释放锁后，ZK会通知机器B, 这样B可以获取锁。

ZK的实现：

zookeeper.create(path…)尝试创建临时节点，创建成功就获取锁；

如果被别的客户端获取了，就注册一个监听器监听这个锁，可以尝试用CountDownLatch await或者别的方式等待，或者不断循环查询，

如果监听这个节点被释放，就把latch countDown或者把等待release，重新尝试获取锁。

也可以基于zookeeper的临时顺序节点来实现，不用while true的循环。多人竞争一把锁时，会排队，后面每个排队的都去监听排在自己前面那个人创建的znode。

元数据/配置信息管理：

ZK可以作为很多系统的配置信息管理，比如Kafka, Storm，Dubbo。

HA高可用：

大数据系统基于ZK开发HA高可用机制，比如Hadoop，HDFS，Yarm。一个进程/服务做主备两个，主挂了立马通过Zookeeper感知切换到备用进程或服务。

Redis分布式锁：

官方叫RedLock，Redis官方支持的分布式锁算法。

分布式锁3个重要考察点：

• 互斥
• 不能死锁
• 容错

1. 普通的加锁方式(setnx)：

SET Key(orderId:1lock) Value(随机值) NX PX 30000

NX：表示只有 key 不存在的时候才会设置成功。（如果此时 redis 中存在这个 key，那么设置失败，返回 nil）

PX 30000：意思是 30s 后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了。

释放锁就是删除 key ，但是一般可以用 lua 脚本删除，判断 value 一样才删除：

删除锁的时候，找到 key 对应的 value，跟自己传过去的 value 做比较，如果是一样的才删除。

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

为什么要用这种方式来删除？

比如A获取锁后，阻塞时间超过30s，锁自动释放了。

B已经获取锁了，要是这个时候直接删除Key（已经是别人加的锁）的话就会出现问题，所有加随机值加上lua脚本(原子操作)来释放锁。

这个方案有单点故障风险。如果redis普通主从，如果主从异步复制，主节点挂了, key失效，key还没有同步到从节点，这时候从节点切换为主节点，

其他人就可以set key，从而拿到锁，分布式锁机制失效。

2. RedLock算法

场景：有redis cluster，5个实例。对集群上锁，在大多数节点上锁成功，就算成功。

上锁步骤：

获取时间戳，轮流在每个主节点上锁，过期时间较短，比如5个节点，要求3个节点(n/2 + 1); 创建锁的时间小于超时时间，表示创建成功；

要是锁创建失败，就依次删除之前建立的锁。

PS:实现比较复杂，在国外还有争议，算法的健壮性可疑。

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

• redis 分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。RedLock算法还不完善。
• zk 分布式锁，获取不到锁，注册监听器即可，不需要不断主动尝试获取锁，性能开销较小。

总结，zk 的分布式锁比 redis 的分布式锁牢靠、而且模型简单易用。

参考资料：

《互联网Java进阶面试训练营》的笔记 -- 中华石杉