分布式锁机制以及各种实现方式

绝地灬酷狼 2023-06-29 05:34 15阅读 0赞

#### 分布式锁的使用场景： ####

*  多台机器都可以定时执行某个任务，如果限制任务每次只能被一台机器执行，不能重复执行
 *  秒杀场景，要求并发量很高，那么同一件商品只能被一个用户抢到
 *  涉及到并发竞争的情况

#### 基于数据库实现 ####

> 乐观锁

乐观锁机制其实就是在数据库表中引入一个版本号（version）字段来实现的。  
当我们要从数据库中读取数据的时候，同时把这个version字段也读出来  
如果要对读出来的数据进行更新后写回数据库，则需要将version加1  
同时将新的数据与新的version更新到数据表中  
在更新的时候同时检查目前数据库里version值是不是之前读出来的version  
如果是，则正常更新  
如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了

> 悲观锁

悲观锁也叫作排它锁，在Mysql中是基于 for update 来实现加锁的

select * from a where id = 100 for update

id是主键，通过 for update 操作，数据库在查询的时候就会给这条记录加上排它锁。  
（需要注意的是，在InnoDB中只有字段加了索引的，才会是行级锁，否者是表级锁，所以这个id字段要加索引）  
当这条记录加上排它锁之后，其它线程是无法操作这条记录的。  
那么，这样的话，我们就可以认为获得了排它锁的这个线程是拥有了分布式锁  
然后就可以执行我们想要做的业务逻辑，当逻辑完成之后，commit执行语句，释放锁

> 基于REDIS实现

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

*  互斥性。在任意时刻，只有一个客户端能持有锁。
 *  不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
 *  具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
 *  解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

##### 加锁操作 #####

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);
    	    
    	    if (LOCK_SUCCESS.equals(result)) { 
    	        return true;
    	    }
    	    return false;
    	}

可以看到，我们加锁就一行代码：

jedis.set(String key, String value, String nxxx, String expx, int time)

这个set()方法一共有五个形参：

*  第一个为key，我们使用key来当锁，因为key是唯一的。
 *  第二个为value，我们传的是requestId，原因就是通过给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.  已有锁存在，不做任何操作。

set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。

由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。

因为我们将value赋值为requestId，代表加锁的客户端请求标识，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。

##### 错误示例1 #####

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

由于这是两条Redis命令，不具有原子性，如果程序在执行完setnx()之后突然崩溃，导致锁没有设置过期时间。那么将会发生死锁。

##### 错误示例2 #####

使用jedis.setnx()命令实现加锁  
执行过程：

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

客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步  
锁不具备拥有者标识，即任何客户端都可以解锁。

##### 解锁操作 #####

// 首先获取锁对应的value值，检查是否与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));
    
    if (RELEASE_SUCCESS.equals(result)) { 
        return true;
    }
    return false;

*  第一行代码，我们写了一个简单的Lua脚本代码。
 *  第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS\[1\]赋值为lockKey，ARGV\[1\]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

使用eval的原因：在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。保证原子性

##### 错误示例1 #####

直接使用jedis.del()方法删除锁

导致任何客户端都可以随时进行解锁

##### 错误示例2 #####

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

问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。

比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。

> 基于 REDISSON 做分布式锁

在Redisson中，使用key来作为是否上锁的标志，当通过getLock(String key)方法获得相应的锁之后，这个key即作为一个锁存储到Redis集群中，在接下来如果有其他的线程尝试获取名为key的锁时，便会向集群中进行查询，如果能够查到这个锁并发现相应的value的值不为0，则表示已经有其他线程申请了这个锁同时还没有释放，则当前线程进入阻塞，否则由当前线程获取这个锁并将value值加一，如果是可重入锁的话，则当前线程每获得一个自身线程的锁，就将value的值加一，而每释放一个锁则将value值减一，直到减至0，完全释放这个锁。因为底层是基于分布式的Redis集群，所以Redisson实现了分布式的锁机制。

##### redlock算法 #####

假设有5个redis master实例。然后执行如下步骤获取一把锁：

1）获取当前毫秒时间戳  
2）轮流尝试在每个master节点上创建锁，过期时间较短，一般就几十毫秒  
3）尝试在大多数master节点上建立一个锁，比如5个节点就要求是至少3个节点（n / 2 +1）  
4）客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了  
5）要是锁建立失败了，那么就依次删除这个锁  
6）只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁

> 基于zookeeper做分布式锁

如果客户端需要加锁，就会在zk上面注册一个临时节点，创建成功说明加锁成功，这个时候再有客户端进行加锁，则提示加锁失败，然后客户端就会在zk上注册一个监听器，如果zk发现当前的锁释放了，就会通知客户端去获取锁  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjMxNzk3_size_16_color_FFFFFF_t_70]

##### 临时顺序节点加锁过程 #####

多个客户端竞争一把锁，这时候zk会将所有的请求接收，然后给每一个客户端创建一个顺序节点这时候就相当于进行了排队处理，每一个节点都会监听上一个节点持有锁的状态，当上一个节点释放锁之后，zk会通知释放锁节点的下一个节点，这时候下一个节点就会持有锁，然后运行代码

##### redis和zk实现分布式锁的区别 #####

redis分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能

zk分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小

另外一点就是，如果是redis获取锁的那个客户端bug了或者挂了，那么只能等待超时时间之后才能释放锁；而zk的话，因为创建的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjMxNzk3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200110143852596.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjMxNzk3,size_16,color_FFFFFF,t_70