Zookeeper与Redis 对比

1. 为什么使用分布式锁？

    使用分布式锁的目的，是为了保证同一时间只有一个 JVM 进程可以对共享资源进行操作。

根据锁的用途可以细分为以下两类：

    1、 允许多个客户端操作共享资源，我们称为共享锁。

           这种锁的一般是对共享资源具有幂等性操作的场景，主要是为了避免重复操作共享                 资源频繁加锁带来的性能开销。

    2、 只允许一个客户端操作共享资源，我们成为排他锁。

           这种锁一般是用在对共享资源操作具有非幂等性操作的场景，也就是需要保证在同                 一时刻只有一个进程或者线程能够访问这个共享资源。

2. 目前实现分布式锁最常用的中间件是 Redis和Zookeeper

**a、第一种，Redis 可以通过两种方式来实现 **

            i. 利用 Redis 提供的`SET key value NX PX milliseconds `指令，这个指令是设                           置一个 key-value，如果 key 已经存在，则返回 0，否则返回 1， 我们基于这个                     返回值来判断锁的占用情况从而实现分布式锁。

            ii. 基于 Redission 客户端来实现分布式锁，Redisson 提供了分布式锁的封装方                          法，我们只需要调用 api 中的`lock（）`和`unlock()`方法。它帮我们封装锁实现                      的细节和复杂度

                            1. redisson 所有指令都通过 lua 脚本执行并支持 lua 脚本原子性执行

                            2. redisson 中有一个 watchdog 的概念，翻译过来就是看门狗，它会在                                      你获取锁之后，每隔 10 秒帮你把 key 的超时时间设为 30s，就算一                                        直持有锁也不会出现 key 过期了。

                                “看门狗”的逻辑保证了没有死锁发生。

b. 第二种，基于 ZK 实现分布式锁的落地方案

** **Zookeeper 实现分布式锁的方法比较多，我们可以使用有序节点来实现。

             i. 每个线程或进程在 Zookeeper 上的`/lock`目录下创建一个临时有序的节点表示                        去抢占锁，所有创建的节点会按照先后顺序生成一个带有序编号的 节点。

             ii. 线程创建节点后，获取/lock 节点下的所有子节点，判断当前线程创建的节点是                       否是所有的节点的序号最小的。

             iii. 如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。

             iv. 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一                       个节点添加一个事件监听，当前一个被监听的节点释放锁之后，触发回调通                            知，从而再次去尝试抢占锁。

3. 两种方案都有各自的优缺点

对于 redis 的分布式锁而言，它有以下缺点：

1、它获取锁的方式简单粗暴，如果获取不到锁，会不断尝试获取锁，比较消耗性能。

2、Redis 是 AP 模型，在集群模式中由于数据的一致性会导致锁出现问题，即便使用 Redlock 算法来实现，在某些复杂场景下，也无法保证其实现 100%的可靠性。 不过在 实际开发中使用 Redis 实现分布式锁还是比较常见，而且大部分场情况下不会遇 到”极端 复杂的场景“，更重要的是 Redis 性能很高，在高并发场景中比较合适。

补充：

    明显AP结构选择了高可用和分区容错性，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。Eureka就是一个AP架构的例子，当Eureka客户端心跳消失的时候，那Eureka服务端就会启动自我保护机制，不会剔除该EurekaClient客户端的服务，依然可以提供需求；

对于 zk 分布式锁而言

1、zookeeper 天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、 适合 做分布式锁。

2、 如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。 如 果要在两者之间做选择，就个人而言的话，比较推崇 ZK 实现的锁，因为对于分布 式 锁言，它应该符合 CP 模型，但是 Redis 是 AP 模型，所以在这个点上，Zookeeper 会更 加合适。