微服务架构之：基于Redis的分布式锁优化（Redisson）

    在此之前先看一看我们搭建的Redis分布式锁3.0版本微服务架构之：Redis的分布式锁—搭建生产可用的Redis分布式锁

基于setnx实现分布式锁存在下面的问题

不可重入

    可重入锁就是指一个线程可用多次获取同一把锁。比如说有一个方法a()调用方法b()，在方法a中要先获取锁，然后执行业务去调用方法b。这时候如果锁时不可重入的，那么在a()里获取的锁，在b()时又想获取这把锁，显然是无法获取的，所以这时候就回去等待a()锁的释放，而锁时无法释放的，于是就会出现死锁。所以在这个场景下就要要求锁时可重入的。

不可重试

    我们之前实现的锁时非阻塞式，我们尝试获取锁如果失败会立即返回false，没有重试的机制。但是在很多业务下锁没获取到的线程不能立即失败，我们希望的是乐观锁自旋的思想，在没获取到的时候重新再次尝试获取锁，等成功了在执行业务。

超时释放

    虽然我们解决了超时释放误删别人线程锁的问题。但是这个超时的情况还是有可能发生的，虽然不会误删，但是还可能有其他的隐患。所以这个超时释放问题还是要解决，如果这个时间设置的太短，我们的业务还没执行完锁就释放了，这样一来我的业务执行过程中其他线程也有可能执行。这是一个风险，但是如果设置的太长，万一出现了故障，在很长的一段时间里都要等待这个锁的释放，这样的锁的阻塞周期就过长。这是一个矛盾，也需要去解决。

主从一致性问题

    如果Redis提供了主从集群（就是读写分离），主从同步存在延迟（子线程加载RDB的执行操作，就是写、改、删操作）。我们在主机那获取了锁（setnx），因为存在延迟，在还没有同步到从节点的时候，主机宕机。这个时候会选一个从机当主机，但是从机没有这个锁，所以就会有多个线程拿到锁，可能会出现线程安全问题。但是出现的概率很低，因为延迟太小了。

    虽然这些问题多多少少都存在隐患，但是概率小到可以忽略不计，自己去实现代价太多，但是不实现心里总不踏实，所以我们来找找有没有什么成熟的框架可以让我们直接调用。（Redisson）

Redisson

    Redisson是一个成熟的在Redis基础上实现的Java驻内存的数据网格。说句人话，之前上一章的内容白学了，因为这里有更成熟，更安全的组件qwq
    它不仅提供了一系列分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。

官网：https://redisson.org/（外网，可能有点卡）

Redisson入门

1. 引入依赖
   
2. 配置Redisson客户端
   
3. 使用Redisson的分布式锁（阻塞式，可重入，可重试）