这几种常见的“分布式锁”写法，搞懂再也不怕面试官，安排( 四 ) _分布式锁

我们看了下依然丝滑，源码我就不分析了，感兴趣的可以看我同事的博客 Curator的ZK分布式锁实现原理。
总结zookeeper 天生设计定位就是分布式协调，强一致性，锁很健壮。如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。缺点：在高请求高并发下，系统疯狂的加锁释放锁，最后 zk 承受不住这么大的压力可能会存在宕机的风险。

在这里简单的提一下，zk 锁性能比 redis 低的原因：zk 中的角色分为 leader，flower，每次写请求只能请求 leader，leader 会把写请求广播到所有 flower，如果 flower 都成功才会提交给 leader，其实这里相当于一个 2PC 的过程。在加锁的时候是一个写请求，当写请求很多时，zk 会有很大的压力，最后导致服务器响应很慢。

redis 锁实现简单，理解逻辑简单，性能好，可以支撑高并发的获取、释放锁操作。缺点： Redis 容易单点故障，集群部署，并不是强一致性的，锁的不够健壮； key 的过期时间设置多少不明确，只能根据实际情况调整；需要自己不断去尝试获取锁，比较消耗性能。
最后不管 redis 还是 zookeeper，它们都应满足分布式锁的特性：