redis实现分布式锁代码实践和场景问题解决方案

Redis为什么性能高?
1、Redis基于内存的
2、Redis基于单线程，较少线程上下文切换
3、Redis的基于NIO的多路复用机制
4、Redis底层多种数据结构，得益于数据存储结构

使用redis原子性命令解决分布式锁问题刨析

1、保证加锁LockKey唯一性
2、保证加锁KEY和expire设置过期时间是一条原子性命令
3、finally {}语句块中释放锁，保证释放是当前线程的Redis分布式锁。在加锁之前生成一个clientId
在最后再判断当前clientId是否一致，然后再释放Redis分布式锁
4、极限情况下，请查看如下代码

finally {
            // 在解锁前添加一个uuid判断当前删除是否是当前请求的锁
            // (问题：判断和删除锁不是原子性的，假设极限情况下key设置的过期时间是10秒)
            if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
                // 刚好执行完这个判断时候9.9秒，突然线程阻塞或者垃圾回收，锁过期了，这个时候其他线程并发仍然能加锁成功
                // 此时线程接着执行删除逻辑，释放的是下一个线程的锁，所有的问题都和锁过期时间有关，所以需要锁续命

                // 5、释放锁（问题：如果异常系统宕机无法释放锁，所以在加锁前要设置过期时间）
                stringRedisTemplate.delete(lockKey);
            }

如果在删除锁之前，Redis的Key刚好过期，也可能导致释放其他线程锁。
这里就需要给锁设置续命规则
引入Watch Dog看门狗程序：
通过定时任务，每隔10秒检查锁是否失效，对锁进行续命
解决方案：Redisson框架的底层实现机制（下面代码有示例）

总结：Redis分布式锁所有场景问题都和Key的过期时间有关联

   /**
     * 使用redis原子性命令解决分布式锁
     */
    @PostMapping("/buyProduct1")
    public String buyProduct1() {

        // 1、key代表商品唯一标识，保证永远只会有一个请求成功获取锁
        final String lockKey = "lockKey_product1";
        final String clientId = UUID.randomUUID().toString();

        // 2、redis的setNx原子命令解决分布式锁
        // redis的setNx原子命令解决分布式锁，保证加锁和过期时间设置原子性
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId);
        // 给当前锁设置过期时间，避免死锁（问题：加锁和设置过期时间不是原子操作）
        stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS);

        if (Boolean.FALSE.equals(flag)) {
            return null;
        }

        // 3、返回 true代表获取分布式锁成功 （问题：假设过期时间设置过段，导致业务逻辑未执行完毕，stringRedisTemplate.delete删除别的请求线程锁）
        // 15s-->10s --> 5s / 8s-->5s --> 3s/ 6s-->5s --> 1s 假设多线程高并发请求，后续线程锁会一直被释放，导致锁失效
        // 问题：自己加的锁，被别的请求删掉了（解决方案，在解锁前添加一个uuid判断当前删除是否是当前请求的锁）
        try {
            // 从Redis获取库存
            int stock = Integer.parseInt(Objects.requireNonNull(stringRedisTemplate.opsForValue().get("stock")));
            if (stock <= 0) {
                System.out.println("扣减库存失败，库存不足");
                return null;
            }

            // 4、扣减完毕直接更新库存
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
            System.out.println("扣减库存成功，剩余库存realStock = " + realStock);

        } catch (NumberFormatException e) {
            e.printStackTrace();
        } finally {
            // 在解锁前添加一个uuid判断当前删除是否是当前请求的锁
            // (问题：判断和删除锁不是原子性的，假设极限情况下key设置的过期时间是10秒)
            if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
                // 刚好执行完这个判断时候9.9秒，突然线程阻塞或者垃圾回收，锁过期了，这个时候其他线程并发仍然能加锁成功
                // 此时线程接着执行删除逻辑，释放的是下一个线程的锁，所有的问题都和锁过期时间有关，所以需要锁续命

                // 5、释放锁（问题：如果异常系统宕机无法释放锁，所以在加锁前要设置过期时间）
                stringRedisTemplate.delete(lockKey);
            }
        }
        return null;
    }

Redisson实现分布式锁解决锁续命问题

 /**
     * 使用redis原子性命令解决分布式锁
     */
    @PostMapping("/buyProduct1")
    public String buyProduct1() {

        // 1、key代表商品唯一标识，保证永远只会有一个请求成功获取锁
        final String lockKey = "lockKey_product1";

        // 2、获取锁对象
        RLock redissonLock = redisson.getLock(lockKey);
        redissonLock.lock();
        try {
            // 从Redis获取库存
            int stock = Integer.parseInt(Objects.requireNonNull(stringRedisTemplate.opsForValue().get("stock")));
            if (stock <= 0) {
                System.out.println("扣减库存失败，库存不足");
                return null;
            }
            // 扣减完毕直接更新库存
            int realStock = stock - 1;
            stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
            System.out.println("扣减库存成功，剩余库存realStock = " + realStock);

        } catch (NumberFormatException e) {
            e.printStackTrace();
        } finally {
            // 3、释放锁
            redissonLock.unlock();
        }
        return null;
    }

Redisson实现分布式锁原理

Redis分布式锁

1、加锁机制
线程去获取锁，获取成功: 执行 lua脚本，保存数据到 redis数据库。
2、watch dog自动延期机制
在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(不设置默认30秒），这样的目的主要是防止死锁的发生。

但在实际开发中会有下面一种情况：

 1 //设置锁1秒过去
 2 redissonLock.lock("redisson", 1);
 3 /**
 4  * 业务逻辑需要咨询2秒
 5  */
 6 redissonLock.release("redisson");
 7 
 8 /**
 9 * 线程1 进来获得锁后，线程一切正常并没有宕机，但它的业务逻辑需要执行2秒，这就会有个问题，在 线程1 执行1秒后，这个锁就自动过期了，
10 * 那么这个时候 线程2 进来了。那么就存在 线程1和线程2 同时在这段业务逻辑里执行代码，这当然是不合理的。
11 * 而且如果是这种情况，那么在解锁时系统会抛异常，因为解锁和加锁已经不是同一线程了
12 */

所以这个时候看门狗就出现了，它的作用就是 线程1 业务还没有执行完，时间就过了，线程1 还想持有锁的话，就会启动一个 watch dog后台线程，不断的延长锁 key的生存时间。
注意：正常这个看门狗线程是不启动的，还有就是这个看门狗启动后对整体性能也会有一定影响，所以不建议开启看门狗。

Redis分布式锁提升性能的方案

1、通过控制代码层加锁的粒度，提升性能
2、通过分段锁提升性能。

Redis分段锁