分布式锁定义

分布式锁在分布式环境下，锁定全局唯一公共资源，表现为：

• 请求串行化
• 互斥性

第一步是上锁的资源目标，是锁定全局唯一公共资源，只有是全局唯一的资源才存在多个线程或服务竞争的情况。

互斥性表现为一个资源的隔离级别串行化，如果对照单机事务 ACID 的隔离性来说，互斥性的事务隔离级别是 SERLALIZABLE，属于最高的隔离级别。

事务隔离级别：

• DEFAULT
• READ_UNCOMMITTED
• READ_COMMITED
• REPEATABLE_READ
• SERLALIZABLE

分布式锁目的

分布式锁的目的如下：

• 解决业务层幂等性
• 解决 MQ 消费端多次接受同一消息
• 确保串行|隔离级别
• 多台机器同时执行定时任务

寻找唯一资源进行上锁

例子：

1. 防止用户重复下单 共享资源进行上锁的对象 ： 【用户id】2. 订单生成后发送MQ给消费者进行积分的添加 寻找上锁的对象 ：【订单id】3. 用户已经创建订单，准备对订单进行支付，同时商家在对这个订单进行改价 寻找上锁对象 ： 【订单id】

基于 Redis 分布式锁

Redis 单线程串行处理天然就是解决串行化问题，用来解决分布式锁是再适合不过。

实现方式：

setnx key value Expire_time 获取到锁 返回 1 ， 获取失败 返回 0

存在问题如下：

锁时间不可控

Redis 只能在 Setnx 指定一个锁的超时时间，假设初始设定锁的时间是 10 秒钟，但是业务获取到锁跑了 20 秒钟，在 10 秒钟之后，如果又有一个业务可以获取到相同的一把锁。

这个时候可能就存在两个相同的业务都获取得到锁的问题，并且两个业务处在并行阶段。也就是第一个获取锁的业务无法对自身的锁进行续租。

单点连接超时问题

Redis 的 Client 与 Server 端并没有维持心跳的机制，如果在连接中出现问题，Client 会得到一个超时的回馈。

主从问题

Redis 的集群实际上在 CAP 模式中是处在与 AP 的模型，保证可用性。在主从复制中“主”有数据，但可能“从”还没有数据。这个时候，一旦主挂掉或者网络抖动等各种原因，可能会切换到“从”节点。

这个时候有可能会导致两个业务线程同时的获取到两把锁：

①业务线程-1：向主节点请求锁

②业务线程-1：获取锁

③业务线程-1：获取到锁并开始执行业务

④这个时候 Redis 刚生成的锁在主从之间还未进行同步

⑤Redis 这时候主节点挂掉了

⑥Redis 的从节点升级为主节点

⑦业务线程-2：向新的主节点请求锁

⑧业务线程-2：获取到新的主节点返回的锁

⑨业务线程-2：获取到锁开始执行业务

⑩这个时候业务线程-1和业务线程-2同时在执行任务

Redlock

上述的问题其实并不是 Redis 的缺陷，只是 Redis 采用了 AP 模型，它本身无法确保我们对一致性的要求。

Redis 官方推荐 Redlock 算法来保证，问题是 Redlock 至少需要三个 Redis 主从实例来实现，维护成本比较高。

相当于 Redlock 使用三个 Redis 集群实现了自己的另一套一致性算法，比较繁琐，在业界也使用得比较少。

能不能使用 Redis 作为分布式锁

能不能使用 Redis 作为分布式锁，这个本身就不是 Redis 的问题，还是取决于业务场景，我们先要自己确认我们的场景是适合 AP 还是 CP。

如果在社交发帖等场景下，我们并没有非常强的事务一致性问题，Redis 提供给我们高性能的 AP 模型是非常适合的。

但如果是交易类型，对数据一致性非常敏感的场景，我们可能要寻找一种更加适合的 CP 模型。

Redis 可能作为高可用的分布式锁并不合适，我们需要确立高可用分布式锁的设计目标。

高可用分布式锁设计目标

高可用分布式锁的设计目标如下：

• 强一致性，是 CP 模型
• 服务高可用，不存在单点问题
• 锁能够续租和自动释放
• 业务接入简单

三种分布式锁方案对比

常用的三种分布式锁方案对比如下图：

基于 Zookeeper 分布式锁

刚刚也分析过，Redis 其实无法确保数据的一致性，先来看 Zookeeper 是否合适作为我们需要的分布式锁。

首先 ZK 的模式是 CP 模型，也就是说，当 ZK 锁提供给我们进行访问的时候，在 ZK 集群中能确保这把锁在 ZK 的每一个节点都存在。

这个实际上是 ZK 的 Leader 通过二阶段提交写请求来保证的，这个也是 ZK 的集群规模大了的一个瓶颈点。

ZK 锁实现的原理

说 ZK 的锁问题之前先看看 Zookeeper 中的几个特性，这几个特性构建了 ZK 的一把分布式锁。

Zookeeper 中的几个特性如下：

• 有序节点，当在一个父目录下如 /lock 下创建有序节点，节点会按照严格的先后顺序创建出自节点 lock000001，lock000002，lock0000003，以此类推，有序节点能严格保证各个自节点按照排序命名生成。
• 临时节点，客户端建立了一个临时节点，在客户端的会话结束或会话超时，Zookeeper 会自动删除该节点 ID。
• 事件监听，在读取数据时，我们可以对节点设置监听，当节点的数据发生变化(1 节点创建，2 节点删除，3 节点数据变动，4 子节点变动)时，Zookeeper 会通知客户端。

结合这几个特点，来看下 ZK 是怎么组合分布式锁：

• 业务线程-1，业务线程-2 分别向 ZK 的 /lock 目录下，申请创建有序的临时节点。
• 业务线程-1 抢到 /lock0001 的文件，也就是在整个目录下最小序的节点，也就是线程-1 获取到了锁。
• 业务线程-2 只能抢到 /lock0002 的文件，并不是最小序的节点，线程 2 未能获取锁。
• 业务线程-1 与 lock0001 建立了连接，并维持了心跳，维持的心跳也就是这把锁的租期。
• 当业务线程-1 完成了业务，将释放掉与 ZK 的连接，也就是释放了这把锁。

ZK 分布式锁的代码实现

ZK 官方提供的客户端并不支持分布式锁的直接实现，我们需要自己写代码去利用 ZK 的这几个特性去进行实现：

ZK 分布式锁客户端假死的问题

客户端创建了临时有序节点并建立了事件监听，就可以让业务线程与 ZK 维持心跳，这个心跳也就是这把锁的租期。

当客户端的业务线程完成了执行就把节点进行删除，也就释放了这把锁，不过中间也可能存在问题：

• 客户端挂掉。因为注册的是临时节点，客户端挂掉，ZK 会进行感知，也就会把这个临时节点删除，锁也就随着释放。
• 业务线程假死。业务线程并没有消息，而是一个假死状态，(例如死循环，死锁，超长 GC)，这个时候锁会被一直霸占不能释放，这个问题需要从两个方面进行解决。