[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[1]) == ARGV[1] then return redis.call("del",KEYS[1]) 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进阶面试训练营》的笔记 -- 中华石杉