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分段锁
