项目亮点之分布式锁

分布式锁

什么是分布式锁？

我们的手机有锁、车有锁、家门有锁、贵重物品会锁进保险箱。可以说，锁在我们生活中无处不在，时刻保护着我们的人身财产安全。

在计算机领域也一样，锁可以理解为针对某项资源使用权限的管理，它通常用来控制共享资源，比如一个进程内有多个线程竞争一个数据的使用权限，解决方式之一就是加锁。

那分布式锁是什么呢？

顾名思义，分布式锁就是分布式场景下的锁，比如多台不同机器上的进程，去竞争同一项资源，就是分布式锁。

为了保证一个方法在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。

但是，随着业务发展的需要，原单体部署的系统被演化成分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效；

img

为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。

分布式锁应该具有以下几个特征：

  • 互斥性：锁的目的是获取资源的使用权，所以只让一个竞争者持有锁，这一点要尽可能保证；
  • 安全性：避免死锁情况发生。当一个竞争者在持有锁期间内，由于意外崩溃而导致未能主动解锁，其持有的锁也能够被正常释放，并保证后续其它竞争者也能加锁；
  • 对称性：同一个锁，加锁和解锁必须是同一个竞争者。不能把其他竞争者持有的锁给释放了，这又称为锁的可重入性。
  • 可靠性：需要有一定程度的异常处理能力、容灾能力。

Java分布式锁总结

数据库分布式锁

要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录.

具体操作就是在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。

创建数据库

CREATE TABLE `database_lock` (
    `id` BIGINT NOT NULL AUTO_INCREMENT,
    `resource` int NOT NULL COMMENT '锁定的资源',
    `description` varchar(1024) NOT NULL DEFAULT "" COMMENT '描述',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uiq_idx_resource` (`resource`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='数据库分布式锁表';

操作流程

1、加锁

当我们需要给某个资源添加锁的时候，就插入一条数据

INSERT INTO database_lock(resource, description) VALUES (1, ‘lock’);

resource字段是唯一索引，多个请求请求添加同一条数据，那么其他的就会报错。

2、 释放锁

释放锁时，删除当前条数据

DELETE FROM database_lock WHERE resource=1;

然后其他资源就可以再次添加去获取这个锁了。

问题

上面这种简单的实现有以下几个问题：

  1. 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
  2. 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
  3. 这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
  4. 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

当然，我们也可以有其他方式解决上面的问题。

  • 数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
  • 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
  • 非阻塞的？搞一个while循环，直到insert成功再返回成功。
  • 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

优点：借助数据库，方案简单。

缺点：在实际实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑

Zookeeper分布式锁

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

基于ZooKeeper实现分布式锁的步骤如下：

  1. 创建一个目录mylock；
  2. 线程A想获取锁就在mylock目录下创建临时顺序节点；
  3. 获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
  4. 线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
  5. 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。具体说明如下：

  • 锁无法释放，造成死锁！使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
  • 阻塞锁特性！使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
  • 可重入！使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
  • 单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。

Redis分布式锁

分布式锁，一般会依托第三方组件来实现，而利用Redis实现则是工作中应用最多的一种。
今天，就让我们从最基础的步骤开始，依照分布式锁的特性，层层递进，步步完善，将它优化到最优，让大家完整地了解如何用Redis来实现一个分布式锁。

简化版本

setnx key value

首先，当然是搭建一个最简单的实现方式，直接用Redis的setnx命令，这个命令的语法是：

setnx key value

如果key不存在，则会将key设置为value，并返回1；如果key存在，不会有任务影响，返回0。

基于这个特性，我们就可以用setnx实现加锁的目的：通过setnx加锁，加锁之后其他服务无法加锁，用完之后，再通过delete解锁，深藏功与名。

img

示例代码：

// 1.先抢占锁
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "123");
if (lock) {
  // 2.抢占成功，执行业务
  Object object = doSomeThing();
  // 3.解锁
  redisTemplate.delete("lock");
  return object;
} else {
  // 4.休眠一段时间
  sleep(100);
  // 5.抢占失败，等待锁释放
  return doSomethingsByRedisDistributedLock();
}

支持过期时间

最简化版本有一个问题：如果获取锁的服务挂掉了，那么锁就一直得不到释放，就像石沉大海，杳无音信。所以，我们需要一个超时来兜底。

expire

Redis中有expire命令，用来设置一个key的超时时间。

示例代码：

// 1.先抢占锁
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "123");
if(lock) {
    // 2.在 10s 以后，自动清理 lock
    redisTemplate.expire("lock", 10, TimeUnit.SECONDS);
    // 3.抢占成功，执行业务
    Object object = doSomeThing();
    // 4.解锁
    redisTemplate.delete("lock");
    return object;
}

但是setnx和expire不具备原子性，如果setnx获取锁之后，服务挂掉，依旧是泥牛入海。

很自然，我们会想到，set和expire，有没有原子操作？

当然有，Redis早就考虑到了这种场景，推出了如下执行语句：

set key value nx ex seconds

nx表示具备setnx特定，ex表示增加了过期时间，最后一个参数就是过期时间的值。

img

能够支持过期时间，目前这个锁基本上是能用了。

示例代码：

setIfAbsent("lock", "123", 10, TimeUnit.SECONDS);

但是存在一个问题：会存在服务A释放掉服务B的锁的可能。

支持owner锁

我们来试想一下如下场景：服务A获取了锁，由于业务流程比较长，或者网络延迟、GC卡顿等原因，导致锁过期，而业务还会继续进行。这时候，业务B已经拿到了锁，准备去执行，这个时候服务A恢复过来并做完了业务，就会释放锁，而B却还在继续执行。

在真实的分布式场景中，可能存在几十个竞争者，那么上述情况发生概率就很高，导致同一份资源频繁被不同竞争者同时访问，分布式锁也就失去了意义。

uuid

基于这个场景，我们可以发现，问题关键在于，竞争者可以释放其他人的锁。那么在异常情况下，就会出现问题，所以我们可以进一步给出解决方案：分布式锁需要满足谁申请谁释放原则，不能释放别人的锁，也就是说，分布式锁，是要有归属的。

img

示例代码：

// 1.生成唯一 id
String uuid = UUID.randomUUID().toString();
// 2. 抢占锁
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid, 10, TimeUnit.SECONDS);
if(lock) {
    System.out.println("抢占成功：" + uuid);
    // 3.抢占成功，执行业务
        Object object = doSomeThing();
    // 4.获取当前锁的值
    String lockValue = redisTemplate.opsForValue().get("lock");
    // 5.如果锁的值和设置的值相等，则清理自己的锁
    if(uuid.equals(lockValue)) {
        System.out.println("清理锁：" + lockValue);
        redisTemplate.delete("lock");
    }
    return object;
} else {
    System.out.println("抢占失败，等待锁释放");
    // 4.休眠一段时间
    sleep(100);
    // 5.抢占失败，等待锁释放
    return doSomethingsByRedisDistributedLock();
}

支持原子操作

加入owner后的版本可以称得上是完善了吗？还有没有什么隐患呢？

小编也不卖关子了，到这一步其实还存在一个小问题，我们完整的流程是竞争者获取锁执行任务，执行完毕后检查锁是不是自己的，最后进行释放。

流程一梳理，你们肯定明白了，执行完毕后，检查锁，再释放，这些操作不是原子化的。

可能锁获取时还是自己的，删除时却已经是别人的了。这可怎么办呢？

lua

Redis可没有直接提供这种场景原子化的操作啊。遇事不要慌，仔细想一想，Redis是不是还有个特性，专门整合原子操作，对，就是它——Lua。

Redis➕Lua，可以说是专门为解决原子问题而生。

有了Lua的特性，Redis才真正在分布式锁、秒杀等场景，有了用武之地，下面便是改造之后的流程：

img

redis中的脚本：

if redis.call("get",KEYS[1]) == ARGV[1]
then
    return redis.call("del",KEYS[1])
else
    return 0
end

分两步执行这段脚本：先定义脚本；用 redisTemplate.execute 方法执行脚本。

// 脚本解锁
String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class), Arrays.asList("lock"), uuid);

上面的代码中，KEYS[1] 对应lock，ARGV[1] 对应 uuid，含义就是如果 lock 的 value 等于 uuid 则删除 lock。

这段 Redis 脚本是由 Redis 内嵌的 Lua 环境执行的，所以又称作 Lua 脚本。

支持自动续期

这里还会有一个问题，就是Redis分布式锁无法自动续期，比如，一个锁设置了1分钟超时释放，如果拿到这个锁的线程在一分钟内没有执行完毕，那么这个锁就会被其他线程拿到，可能会导致严重的线上问题。

Redisson

我们可以这样做，在锁将要过期的时候，如果服务还没有处理完业务，那么将这个锁再续一段时间。比如设置key在10s后过期，那么再开启一个守护线程，在第8s的时候检测服务是否处理完，如果没有，则将这个key再续10s后过期。

在Redisson（Redis SDK客户端）中，就已经帮我们实现了这个功能，这个自动续时的我们称其为”看门狗”。

img

Redisson提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期，也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。

默认情况下，看门狗的续期时间是30s，也可以通过修改Config.lockWatchdogTimeout来另行指定。另外Redisson 还提供了可以指定leaseTime参数的加锁方法来指定加锁的时间。超过这个时间后锁便自动解开了，不会延长锁的有效期。

可靠性

可靠性保证

其实到了这一步，分布式锁的前三个特性：对称性、安全性、可靠性，就满足了。可以说是一个可用的分布式锁了，能满足大多数场景的需要。

分布式锁的四大特性还剩下可靠性没有解决。

针对一些异常场景，包括Redis挂掉了、业务执行时间过长、网络波动等情况，我们来一起分析如何处理。

容灾考虑

前面我们谈及的内容，基本是基于单机考虑的，如果Redis挂掉了，那锁就不能获取了。这个问题该如何解决呢？

一般来说，有两种方法：主从容灾和多机部署。

主从容灾

最简单的一种方式，就是为Redis配置从节点，当主节点挂了，用从节点顶包。

img

但是主从切换，需要人工参与，会提高人力成本。不过Redis已经有成熟的解决方案，也就是哨兵模式，可以灵活自动切换，不再需要人工介入。

img

通过增加从节点的方式，虽然一定程度解决了单点的容灾问题，但并不是尽善尽美的，由于同步有时延，Slave可能会损失掉部分数据，分布式锁可能失效，这就会发生短暂的多机获取到执行权限。

有没有更可靠的办法呢？

多机部署

如果对一致性的要求高一些，可以尝试多机部署，比如Redis的RedLock，大概的思路就是多个机器，通常是奇数个，达到一半以上同意加锁才算加锁成功，这样，可靠性会向ETCD靠近。

现在假设有5个Redis主节点，基本保证它们不会同时宕掉，获取锁和释放锁的过程中，客户端会执行以下操作：

  1. 向5个Redis申请加锁；
  2. 只要超过一半，也就是3个Redis返回成功，那么就是获取到了锁。如果超过一半失败，需要向每个Redis发送解锁命令；
  3. 由于向5个Redis发送请求，会有一定时耗，所以锁剩余持有时间，需要减去请求时间。这个可以作为判断依据，如果剩余时间已经为0，那么也是获取锁失败；
  4. 使用完成之后，向5个Redis发送解锁请求。

img

这种模式的好处在于，如果挂了2台Redis，整个集群还是可用的，给了运维更多时间来修复。

另外，多说一句，单点Redis的所有手段，这种多机模式都可以使用，比如为每个节点配置哨兵模式，由于加锁是一半以上同意就成功，那么如果单个节点进行了主从切换，单个节点数据的丢失，就不会让锁失效了。这样增强了可靠性。

可靠性深究

是不是有RedLock，就一定能保证可靠的分布式锁？

这里先说结论：由于分布式系统中的三大困境（简称NPC），所以没有完全可靠的分布式锁！

让我们来看看RedLock在NPC下的表现。

N：Network Delay（网络延迟）

当分布式锁获得返回包的时间过长，此时可能虽然加锁成功，但是已经时过境迁，锁可能很快过期。RedLock算了做了些考量，也就是前面所说的锁剩余持有时间，需要减去请求时间，如此一来，就可以一定程度解决网络延迟的问题。

P：Process Pause（进程暂停）

比如发生GC，获取锁之后GC了，处于GC执行中，然后锁超时。

img

其他锁获取，这种情况几乎无解。这时候GC回来了，那么两个进程就获取到了同一个分布式锁。

img

也许你会说，在GC回来之后，可以再去查一次啊？

这里有两个问题，首先你怎么知道GC回来了？这个可以在做业务之前，通过时间，进行一个粗略判断，但也是很吃场景经验的；第二，如果你判断的时候是ok的，但是判断完GC了呢？这点RedLock是无法解决的。

C：Clock Drift（时钟漂移）

如果竞争者A，获得了RedLock，在5台分布式机器上都加上锁。为了方便分析，我们直接假设5台机器都发生了时钟漂移，锁瞬间过期了。这时候竞争者B拿到了锁，此时A和B拿到了相同的执行权限。

根据上述的分析，可以看出，RedLock也不能扛住NPC的挑战，因此，单单从分布式锁本身出发，完全可靠是不可能的。要实现一个相对可靠的分布式锁机制，还是需要和业务的配合，业务本身要幂等可重入，这样的设计可以省却很多麻烦。

常用的Redis客户端

概念

  • Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Jedis中的方法调用是比较底层的暴露的Redis的API，也即Jedis中的Java方法基本和Redis的API保持着一致，了解Redis的API，也就能熟练的使用Jedis。

  • Redisson实现了分布式和可扩展的Java数据结构，提供很多分布式相关操作服务，例如，分布式锁，分布式集合，可通过Redis支持延迟队列。和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。Redisson中的方法则是进行比较高的抽象，每个方法调用可能进行了一个或多个Redis方法调用。

  • Lettuce:高级Redis客户端，用于线程安全同步，异步和响应使用，支持集群，Sentinel，管道和编码器。目前springboot默认使用的客户端。

可伸缩

  • Jedis：使用阻塞的I/O，且其方法调用都是同步的，程序流需要等到sockets处理完I/O才能执行，不支持异步。Jedis客户端实例不是线程安全的，所以需要通过连接池来使用Jedis。

    Jedis仅支持基本的数据类型如：String、Hash、List、Set、Sorted Set。

  • Redisson：基于Netty框架的事件驱动的通信层，其方法调用是异步的。Redisson的API是线程安全的，所以可以操作单个Redisson连接来完成各种操作。

    Redisson不仅提供了一系列的分布式Java常用对象，基本可以与Java的基本数据结构通用，还提供了许多分布式服务，其中包括（BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service）。

  • Lettuce：基于Netty框架的事件驱动的通信层，其方法调用是异步的。Lettuce的API是线程安全的，所以可以操作单个Lettuce连接来完成各种操作。

总结

优先使用Lettuce，如果需要分布式锁，分布式集合等分布式的高级特性，添加Redisson结合使用，因为Redisson本身对字符串的操作支持很差。

在一些高并发的场景中，比如秒杀，抢票，抢购这些场景，都存在对核心资源，商品库存的争夺，控制不好，库存数量可能被减少到负数，出现超卖的情况，或者产生唯一的一个递增ID，由于web应用部署在多个机器上，简单的同步加锁是无法实现的，给数据库加锁的话，对于高并发，1000/s的并发，数据库可能由行锁变成表锁，性能下降会厉害。那相对而言，redis的分布式锁，相对而言，是个很好的选择，redis官方推荐使用的Redisson就提供了分布式锁和相关服务。

posted @ 2022-08-18 15:21  Faetbwac  阅读(148)  评论(0)  编辑  收藏  举报