分布式锁常见实现方案总结_setex和setnx-优快云博客

本文链接：https://blog.youkuaiyun.com/java_liuyuan/article/details/139836827

一、Redis

1. SETNX

加锁：

127.0.0.1:6379> SET lockKey uniqueValue EX 3 NX
OK

lockKey：加锁的锁名；
uniqueValue：能够唯一标识锁的随机字符串；
NX：只有当 lockKey 对应的 key 值不存在的时候才能 SET 成功；
EX：过期时间设置（秒为单位）EX 3 标示这个锁有一个 3 秒的自动过期时间。与 EX 对应的是 PX（毫秒为单位），这两个都是过期时间设置。

解锁：

// 释放锁时，先比较锁对应的 value 值是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

java 实现方式：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

spring.redis.host=localhost

public String deductStock() {
    String lockKey = "lock:product_101";
    String clientId = UUID.randomUUID().toString();
    Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS); //jedis.setnx(k,v)
    if (!result) {
        return "error_code";
    }
    try {
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); // jedis.get("stock")
        if (stock > 0) {
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock", realStock + ""); // jedis.set(key,value)
            System.out.println("扣减成功，剩余库存:" + realStock);
        } else {
            System.out.println("扣减失败，库存不足");
        }
    } finally {
        if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
            // 卡在这里，锁过期了，其他线程又可以加锁，此时又把其他线程新加的锁删掉了
            stringRedisTemplate.delete(lockKey);
        }
    }
    return "end";
}

SETNX的坑：

锁失效之后，别人加锁成功，自己把别人的锁删了：
- 所以这里需要uniqueValue，也就是唯一标识锁的随机字符串，不是自己的锁不要释放。
即使判断了uniqueValue，但是因为程序卡住，判断完uniqueValue以后，锁过期了，其他线程又可以加锁，此时又把其他线程新加的锁删掉了：
- 使用锁续期（Timer）
过期时间设置不合理，任务未完成但是锁失效了：
- 使用锁续期（Timer），使用Timer，每隔一段时间就给锁续期，除非线程自己主动删除。这也是Redisson的实现思路。

2. Redisson（推荐）

特点：

自带自动续期机制（看门狗）
内置了多种类型的锁比如可重入锁（Reentrant Lock）、自旋锁（Spin Lock）、公平锁（Fair Lock）、多重锁（MultiLock）、红锁（RedLock）、读写锁（ReadWriteLock）

<dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-boot-starter</artifactId>
            <version>3.19.1</version>
        </dependency>

@Configuration
public class RedissonConfiguration {

    @Bean
    public RedissonClient getRedissonClient() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        return Redisson.create(config);
    }
}

public void redissonLock() {

        // 1.获取指定的分布式锁对象
        RLock lock = redisson.getLock("lock");
        // 2.拿锁且不设置锁超时时间，具备 Watch Dog 自动续期机制
        lock.lock();
        // 手动给锁设置过期时间，不具备 Watch Dog 自动续期机制
        lock.lock(10, TimeUnit.SECONDS);
        // 还有lock.tryLock方法，非阻塞锁，如果拿不到锁，则直接返回，不会阻塞

        // 3.执行业务...

        // 4.释放锁
        lock.unlock();
    }

二、ZooKeeper

1. ZooKeeper

不要重复造轮子，直接用Curator

实现原理：
临时节点具备数据自动删除的功能。当client与ZooKeeper连接和session断掉时，相应的临时节点就会被删除。zk有瞬时和持久节点，瞬时节点不可以有子节点。会话结束之后瞬时节点就会消失，ZooKeeper 分布式锁就是基于临时顺序节点和 Watcher（事件监听器）实现的。

获取锁：

首先我们要有一个持久节点/locks，客户端获取锁就是在locks下创建临时顺序节点。
假设客户端 1 创建了/locks/lock1节点，创建成功之后，会判断 lock1是否是 /locks 下最小的子节点。
如果 lock1是最小的子节点，则获取锁成功。否则，获取锁失败。
如果获取锁失败，则说明有其他的客户端已经成功获取锁。客户端 1 并不会不停地循环去尝试加锁，而是在前一个节点比如/locks/lock0上注册一个事件监听器。这个监听器的作用是当前一个节点释放锁之后通知客户端 1（避免无效自旋），这样客户端 1 就加锁成功了。

释放锁：

成功获取锁的客户端在执行完业务流程之后，会将对应的子节点删除。
成功获取锁的客户端在出现故障之后，对应的子节点由于是临时顺序节点，也会被自动删除，避免了锁无法被释放。
我们前面说的事件监听器其实监听的就是这个子节点删除事件，子节点删除就意味着锁被释放。

使用 Redis 实现分布式锁的时候，我们是通过过期时间来避免锁无法被释放导致死锁问题的，而 ZooKeeper 直接利用临时节点的特性即可。假设不使用顺序节点的话，所有尝试获取锁的客户端都会对持有锁的子节点加监听器。当该锁被释放之后，势必会造成所有尝试获取锁的客户端来争夺锁，这样对性能不友好。使用顺序节点之后，只需要监听前一个节点就好了，对性能更友好。

2. ZooKeeper Curator

特点：
Curator主要实现了下面四种锁：

InterProcessMutex：分布式可重入排它锁
InterProcessSemaphoreMutex：分布式不可重入排它锁
InterProcessReadWriteLock：分布式读写锁
InterProcessMultiLock：将多个锁作为单个实体管理的容器，获取锁的时候获取所有锁，释放锁也会释放所有锁资源（忽略释放失败的锁）。

<dependency>
  <groupId>org.apache.curator</groupId>
  <artifactId>curator-recipes</artifactId>
  <version>4.2.0</version>
  <exclusions>
    <exclusion>
      <artifactId>slf4j-api</artifactId>
      <groupId>org.slf4j</groupId>
    </exclusion>
  </exclusions>
</dependency>

@Configuration
public class CuratorConfiguration {

    @Bean(initMethod = "start", destroyMethod = "close")
    public CuratorFramework getCuratorFramework() {
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        return CuratorFrameworkFactory.
                newClient("localhost:2181", retryPolicy);
    }
}

public void zkLock() {
        InterProcessMutex lock = new InterProcessMutex(curatorFramework, "/order");
        try {
            if (lock.acquire(30, TimeUnit.SECONDS)) {
                try {
                    log.info("我获得了锁！！！");
                } finally {
                    lock.release();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

三、Etcd

不会

四、分布式锁的真相

需要满足的几个特性：

互斥：不同线程、进程互斥。
超时机制：临界区代码耗时导致，网络原因导致。可以使用额外的线程续命保证。
完备的锁接口：阻塞的和非阻塞的接口都要有，lock和tryLock。
可重入性：当前请求的节点+ 线程唯一标识。
公平性：锁唤醒时候，按照顺序唤醒。
正确性：进程内的锁不会因为报错死锁，因为崩溃的时候整个进程都会结束。但是多实例部署时死锁就很容易发生，如果粗暴使用超时机制解决死锁问题，就默认了下面这个假设：

锁的超时时间 >> 获取锁的时延 + 执行临界区代码的时间 + 各种进程的暂停（比如 GC）
但上述假设其实无法保证的。

将分布式锁定位为，可以容忍非常小概率互斥语义失效场景下的锁服务。一般来说，一个分布式锁服务，它的正确性要求越高，性能可能就会越低。

五、锁优化：分段加锁逻辑

针对一个商品，要开启秒杀的时候，会将商品的库存预先加载到Redis缓存中，比如有100个库存，此时可以分为5个key，每一个key有20个库存。可以把分布式锁的性能提升5倍。
例如：
product_10111_stock = 100
product_10111_stock1 = 20
product_10111_stock2 = 20
product_10111_stock3 = 20
product_10111_stock4 = 20
product_10111_stock5 = 20
请求来了可以随机可以轮询，扣减完之后就标记不要下次再分配到这个库存。

参考文档：
https://javaguide.cn/distributed-system/distributed-lock-implementations.html
https://mp.weixin.qq.com/s/JzCHpIOiFVmBoAko58ZuGw
https://mp.weixin.qq.com/s/-N4x6EkxwAYDGdJhwvmZLw