分布式锁的几种实现

作者: 秋慕云 | 来源:发表于2019-05-28 10:29 被阅读0次

一、概念

在单机环境中，Java提供了很多API来解决并发问题，如java.util.concurrent包下（简称JUC）的工具类，这些工具类底层不外乎使用synchronized、lock、CAS、volatile、AQS等实现，只能用来解决同一进程中，不同线程对同一资源使用的并发问题，而在分布式的部署环境下，是多进程之间资源的竞争，所以，Java提供的API在分布式场景中就无能为力了。需要通过其他手段，来保证同一时刻操作数据的单一性。

二、分布式锁要满足的几个条件

1. 锁排他性：同一时间，只有一个客户端能获得锁，其他客户端无法同时获取到锁

2. 高可用性：获取或释放锁的机制必须是高可用且性能佳

3.避免死锁：锁在一定时限之后，一定会被释放（无论是正常释放或者异常释放）

三、目前针对分布式锁实现的几种方案

基于数据库实现分布式锁
基于缓存实现分布式锁
基于Zookeeper实现分布式锁

3.1、基于数据库实现分布式锁

3.1.1 通过新建锁表来实现分布式锁：

创建一张锁表，记录锁定的方法名和时间，并对锁的key添加唯一性约束，此处是方法名，建表语句如下:

CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

想要锁住某个方法时，在表中插入一条记录，执行以下SQL：

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’);

因为我们对method_name做了唯一性约束，如果同时有多个请求提交到数据库的话，数据库会保证只有一个可以插入成功，其他的请求则会抛出异常，对于插入数据成功的线程，我认为他获得了后面方法的锁，可以执行之后的方法。

方法执行完毕需要释放锁，需要执行以下Sql:

delete from methodLock where method_name = 'method_name';

3.1.1.2 优缺点：

优点：

直接依赖数据库，易于理解

缺点：

单点问题：锁强依赖数据库的可用性，如果是单点数据库，一旦数据库挂掉，会导致业务系统不可用，解决方法：搭建数据库集群
锁释放问题：锁没有失效时间，当解锁操作失败或发生异常时，锁记录就会一直存在表中，其他线程无法再获得到锁，解决方法：启动一个定时任务，定时清理过期数据。

3.1.1.3 锁特点：

锁是非阻塞的：上面说到，因为method_name做了唯一性约束，同一时间数据库会保证一个插入数据成功，其他请求的线程则会抛出异常，并不会进入等待队列，要想再次获得锁就要重新触发获得锁操作。解决方法：根据实际需要，如果需要获得锁，可以实现while循环，尝试获取锁，直到成功。
锁是非重入锁：同一个线程在没有释放锁之前无法再次获得该锁。因为锁表中该数据已经存在了。解决方法：在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

3.1.2 利用数据库的排他锁实现分布式锁：

基于MySql的InnoDB引擎，可以在查询语句后面增加for update，数据库会对查询结果中的每行都加排他锁，如下SQL：

select * from user_info where user_id = xx for update;

注意：
使用排他锁的时候，一定要有where条件保证检索的数据范围最小，通常需要给user_id列添加索引，保证InnoDB引擎在加锁的时候不用全表扫描，因为只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。

获得排它锁的线程即可获得分布式锁，使用完成之后再通过connection.commit()操作来释放锁。

3.1.2.1 排他锁问题：

MySql会对查询进行优化，是否使用索引是通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。
一个排他锁长时间不提交，就会占用数据库连接，一旦类似的连接变得多了，就可能把数据库连接池撑爆。

3.1.3 通过乐观锁来实现分布式锁：

基于InnoDB存储引擎的表，通过给表中追加一个版本字段来实现，每次更新数据时，把版本作为条件。因为InnoDB默认会为insert、delete、update加上排他锁，所以，可以在更新数据时，使用如下SQL：

update user_info set value = 100 where id = 1 and version = #{version}

3.1.3.1 优缺点

优点：性能比悲观锁高
缺点：会存在大量更新失败异常

3.2、基于缓存实现分布式锁

以Redis为例，实现的锁机制，主要是依赖redis自身的原子操作

3.2.1 缓存基于Jedis实现分布式锁

单点实现，通过如下命令：

SET key value [EX seconds] [PX milliseconds] [NX|XX] （注意：redis版本>=2.6.12）

NX：当键不存在时，才对键进行设置操作，SET key value NX 效果等同于 SETNX key value

PX millisecond：设置键的过期时间为millisecond毫秒，当超过这个时间后，设置的键会自动失效

对应java实现：

引入maven的pom依赖：

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

具体实现：

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

       return LOCK_SUCCESS.equals(result);
    }
}

Java代码：jedis.set(String key, String value, String nxxx, String expx, int time)

参数说明：

第一个为key，我们使用key来当锁，因为key是唯一的。
第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个为time，与第四个参数相呼应，代表key的过期时间

执行上面的set()方法就会导致两种结果：

1.当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端

2.已有锁存在，不做任何操作

3.2.2 使用jedis添加锁的错误使用

错误示例1

比较常见的错误示例就是使用jedis.setnx()和jedis.expire()组合实现加锁，代码如下：

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {

    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
        jedis.expire(lockKey, expireTime);
    }
}

setnx()方法作用就是SET IF NOT EXIST，expire()方法就是给锁加一个过期时间。乍一看好像和前面的set()方法结果一样，然而由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间，那么将会发生死锁。网上之所以有人这样实现，是因为低版本的jedis并不支持多参数的set()方法。

错误示例2

这一种错误示例就比较难以发现问题，而且实现也比较复杂。
实现思路：
使用jedis.setnx()命令实现加锁，其中key是锁，value是锁的过期时间。

执行过程：

通过setnx()方法尝试加锁，如果当前锁不存在，返回加锁成功。
如果锁已经存在则获取锁的过期时间，和当前时间比较，如果锁已经过期，则设置新的过期时间，返回加锁成功。代码如下：

public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {

    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);

    // 如果当前锁不存在，返回加锁成功
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }

    // 如果锁存在，获取锁的过期时间
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && (Long.parseLong(currentValueStr) < System.currentTimeMillis())) {
        // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才有权利加锁
            return true;
        }
    }
    // 其他情况，一律返回加锁失败
    return false;
}

那么这段代码问题在哪里？

由于是客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步。
当锁过期的时候，如果多个客户端同时执行jedis.getSet()方法，那么虽然最终只有一个客户端可以加锁，但是这个客户端的锁的过期时间可能被其他客户端覆盖。
锁不具备拥有者标识，即任何客户端都可以解锁。

正确加锁代码

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

       return RELEASE_SUCCESS.equals(result);
    }
}

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？

其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。

那么为什么要使用Lua语言来实现呢？

因为要确保上述操作是原子性的。关于非原子性会带来什么问题，可以阅读【解锁代码-错误示例2】。那么为什么执行eval()方法可以确保原子性，源于Redis的特性，下面是官网对eval命令的部分解释：

简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

解锁错误示例1

最常见的解锁代码就是直接使用jedis.del()方法删除锁，这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，即使这把锁不是它的。

public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
    jedis.del(lockKey);
}

解锁错误示例2

这种解锁代码乍一看也是没问题，甚至我之前也差点这样实现，与正确姿势差不多，唯一区别的是分成两条命令去执行，代码如下：

public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
        
    // 判断加锁与解锁是不是同一个客户端
    if (requestId.equals(jedis.get(lockKey))) {
        // 若在此时，这把锁突然不是这个客户端的，则会误解锁
        jedis.del(lockKey);
    }
}

如代码注释，问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。

3.2.3 缓存基于Redisson实现分布式锁（推荐）

Redission
Redission的Wiki
可以参考这篇文章➡️Redis分布式锁的实现（Jedis和Redisson两个方案）

3.2.4 基于缓存实现分布式锁存在的问题

单点问题：如果单机redis挂掉了，那么程序会跟着出错
同步问题：如果转移使用 slave节点，复制不是同步复制，会出现多个程序获取锁的情况

3.3、基于Zookeeper实现分布式锁

3.3.1 zookeeper简介

zookeeper（简称zk）：是一种提供配置管理、分布式协同以及命名的中心化服务

抽象模型： zk提供一个多层级的节点命名空间（znode），每个节点都用一个以斜杠（/）分隔的路径表示，而且每个节点都有父节点（根节点除外），类似文件系统。例如，/f1/d2这个表示一个znode，它的父节点为/f1，父父节点为/，而/为根节点没有父节点。这些节点都可以设置关联的数据，为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得ZK不能用于存放大量的数据，每个节点的存放数据上限为1M

有序节点：zk在生成子节点时会根据当前子节点的数量自动添加整数序号，例如： node-0000000000、 node-0000000001**

临时节点：客户端可以建立一个临时节点，在会话结束或者会话超时后，zk会自动删除该节点**

事件监听：创建节点、删除节点、节点数据修改、节点变更 **

3.3.2 建锁过程：

借助zookeeper 临时有序节点 来实现的分布式锁的过程如下：
当每个客户端对某个方法加锁时，在zookeeper上与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。

判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。
当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。

3.3.3 优缺点：

优点：
自动释放锁：在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉

可阻塞：客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，ZK会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。

可重入：客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。

高可用：ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

缺点 :
性能上不如使用缓存实现分布式锁。需要对ZK的原理有所了解。

四、三种方案的比较：

从理解的难易程度角度（从低到高）:数据库 > 缓存 > Zookeeper
从实现的复杂性角度（从低到高）: Zookeeper >= 缓存 > 数据库
从性能角度（从高到低）: 缓存 > Zookeeper >= 数据库
从可靠性角度（从高到低）: Zookeeper > 缓存 > 数据库

参考文章：
分布式锁实现汇总
 Curator
Redis分布式锁的正确实现方式（Java版）
Redis分布式锁的实现（Jedis和Redisson两个方案）