一、Redis 分布式锁
1.1、什么是分布式锁
锁就是用来解决线程安全的，分布式锁又是什么呢？
之前所学过的 synchronized 本质上都是只能在一个进程内部生效的，而在分布式系统中，是有很多进程的（每个服务器都是一个独立的进程），多个进程之间的执行顺序也是不确定的（随机的 ），之前的锁，就很应对分布式系统中多个进程之间产生的制约.
因此，就需要引入 “分布式锁” 来解决上述问题.
分布式锁本质上就是一个公共的服务器，用来记录锁的状态。
Ps：这个公共的服务器可以是Redis, 也可以是其他组件(比如 MySQL 或者 ZooKeeper 等), 还可以是我们自己写的⼀个服务
1.2、分布式锁的基础实现
1.2.1、引入场景
想象这样一个场景：买车票.
实现思路：先查询剩余票数，如果剩余票数 > 0，则设置剩余票数 -= 1.
在没有引入分布式锁之前，就有可能出现以下买票场景：
客户端1 先执行查询余票，发现剩余 1 张，在即将执行 剩余票数 -= 1 过程之前，客户端2 也执行了查询余票，发现也是剩余 1 张，客户端2 也会执行 剩余票数 -= 1. 的过程.
这里就出现了 “超卖” 的场景！！！1 张票，卖给了两个人.
1.2.2、基础实现思想
分布式锁的实现思路很简单，本质上是使用一个/一组 单独的服务器程序，通过用一个键值对来标识锁的状态，来给其他服务器提供 “加锁” 这样的服务.
对于上述场景，进行买票操作过程中，就需要先加锁.
具体的，往 redis 上设置一个特殊的 key - value，接着完成买票操作，再把这个 key - value 删除掉. 如果在 客户端1 买票的期间，客户端2 也想去买票，就也会尝试设置 key - value，如果发现 key - value 已经存在，就分为 “加锁失败”（是放弃还是阻塞，就要看具体的实现策略了）.
这样就保证了 第一个服务器执行 “查询 -> 更新” 过程中，第二个服务器不会执行 “查询” ，也就解决了上述 “超卖” 问题.
Ps：买票的场景使用 mysql 的事务，也可以批量执行 查询 + 修改 操作. 但是分布式系统中，要访问的共享资源不一定是 mysql ....... 也可能是其他存储介质，没有事务. 也可能是执行一段特定的操作，是通过统一的服务器完成指定动作.
1.2.3、引入 setnx
针对于刚刚买票的场景：“key 不存在就设置成功，不存在就设置失败”. 使用 setnx 就可以达到 “加锁” 的效果. 针对解锁，就可以使用 del 命令来完成.
如果某个服务器，加锁成功了（setnx 成功），执行后续逻辑中，还没来得及执行 “解锁” 程序就崩溃了，怎么办？
以前在一个进程中，为了保证解锁的操作能执行到，可以把解锁的操作放到 finally 中，但是这种做法，只是针对进程内的锁有效，针对分布式锁，无效！
比如，服务器直接掉电，进程直接异常终止，这就会导致 redis 上设置的 key 无人删除，也就导致其他服务器无法获取到锁了.
1.3、引入过期时间
针对上述 “没来得及解锁，服务器宕机的情况”，我们可以给 key 设置一个过期时间.
通过 set ex nx 这样的命令完成设置，一旦时间到了，key 就会自动被删除掉.
比如，设置 key 的过期时间，为 1000ms，那么即使出现极端情况，某个服务器挂了，没有真正释放锁，这个锁最多保持 1000ms，也就自动释放了.
可以通过先 setnx ，再使用 expire 的方式设置过期时间么？
不可以！！！务必要使用 set ex nx 的方式来设置！
redis 上多个命令之间，无法保证原子性，即使使用 事务，也不能保证这两个操作都能成功（redis 的事务只能保证不被 “插队”，不能保证操作成功）. 此时就有可能出现 setnx 成功，expire 失败的场景.
1.4、过期时间续约问题（看门狗 Watch Dog）
加锁的时候，给 key 设定 过期时间，设置成多少合适？
- 如果设置的时间过短，就可能在 业务逻辑 还没有执行完，就释放锁了.
- 如果设置的时间太长，就可能导致 “锁释放的不及时” 的问题.
最好的方式就是 “动态续约”.
具体的，初始情况下，设置一个过期时间（比如 1s），在还剩 300ms 的时候（这里的时间不一定是 300ms，数据灵活调整），如果当前任务还没有执行完，就把过期时间续上 1s，等到时间快到了，任务还没执行完，就再续（无限续杯）~
上述过程中，如何知道当前任务还没有执行完，要进行续杯呢？实际上，服务器这边有一个专门的线程，负责续约这个事情，这个线程也叫做 “看门狗”（这是一个比较广义的概念，很多涉及到过期时间的操作都会引入 “看门狗” ）.
这样，即使服务器中途崩溃了，没人负责续约了，锁也能在短时间内自动释放.
这就好比，吃自助餐，老板都是鼓励大家，每次少拿点，少量多次~ 怕的就是你一次拿太多，吃不完，大部分都剩下了. 如果每次少拿点，即使吃不下了，浪费的也不多了.
1.5、引入校验 id
所谓锁，就是 redis 上的普通键值对.
所谓加锁，就是给 redis 上设置一个 key - value.
所谓解锁，就是把 redis 上这个 key - value 删除掉.
是否可能出现 服务器1 执行了加锁，服务器2 执行了解锁？
正常来说，肯定不是故意的，但是代码总会有 bug，不小心执行了解锁操作，就让这锁形同虚设，带来严重后果（比如 超卖）.
为了解决上述问题，就需要引入一点校验机制.
具体的，如下步骤：
1. 给服务器编号，让每个服务器都有一个自己的身份标识.
2. 进行加锁的时候，设置 key - value， key 就表示要针对哪个资源加锁，value 就表示服务器的编号.
后续在解锁的时候，就可以进行校验了. 解锁的时候，先查询一下这个锁对应的服务器编号，然后判定这个编号是否就是当前执行解锁的服务器编号，如果是，才真正执行 del，如果不是，就失效.
通过上述操作，就可以有效避免 “误解锁”.
1.6、引入 lua 脚本
1.6.1、引入 lua 脚本的原因
一个服务器内部，也可能是多线程的. 此时，就可能两个线程都在执行 “解锁” 操作.
例如如下场景：
首先我们知道，解锁的操作分为两步，先通过 GET 服务器编号进行校验，校验成功后在进行 DEL.
在 服务器1 中，线程A 执行 GET 后 线程 B 也执行 GET，然后 线程A 执行 DEL 解锁，此时 线程 B 也执行 DEL 解锁.
上述情况，看起来好像重复执行 DEL 好像问题不大？实则不然！
如果此时还有一个服务器，执行加锁，就可能出问题了.
在 线程A 执行完 DEL 之后，线程 B 执行 DEL 之前，服务器2 的 线程C 正好要执行 加锁(set ex nx)，此时，由于 A 已经解锁了，C 的加锁能成功，但是紧接着，线程 B DEL 就来了，就把 服务器2 刚刚的加锁操作给解除了.
归根结底，还是因为 get 和 del 不是一条原子操作产生的问题.
使用事务，虽然可以解决上述问题（redis 事务虽然弱，但是能够避免插队），但是实践中，往往使用更好的方案 —— lua 脚本.
1.6.2、lua 脚本介绍
lua 语言特别轻量（实现一个 lua 解释器，消耗的体积非常小），可以使用 lua 编写一些逻辑，把这个脚本上传到 redis 服务器上，然后就可以让客户端来控制 redis 执行上述脚本了.
最重要的一点就是，redis 执行一个 lua 脚本，就相当于在 redis 上执行一个命令一样，是原子的. 并且 redis 官方文档中也明确说，lua 就属于是 事务 的替代方案.
例如前面的 “买票” 案例.
if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1])
else
return 0
end;ARGV[1]：表示调用脚本给定的参数，此处要传入一个服务器的 id.
如果 id 和 get 到参数匹配，就进行删除操作.
1.7、引入 redlock 算法
使用 redis 作为分布式锁，redis 本身有没有可能挂了呢？
是很有可能的！
实际工作中的 redis 都是以集群的方式部署的（至少是主从，不会是单机），那么就有可能出现以下大冤种的情况：
服务器1 向 master 节点进行加锁操作. 这个写⼊ key 的过程刚刚完成, master 挂了; slave 节点升级成了新的 master 节点. 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave（主节点和从节点之间的数据同步，是存在延迟的）, 此时 就相当于服务器1 的加锁操作形同虚设了, 服务器2 仍然可以进行加锁.
为了解决以上问题，就提出了 redlock 算法（redis 作者给出的方案）
- 此处加锁，就是按照一定的顺序，针对这组 redis 都进行加锁操作.
- 如果某个节点加不上锁，没关系，可能是 redis 挂了，继续给下一个节点加锁即可.
- 如果写入 key 成功的节点个数超过总数的一半，就视为 加锁成功.
- 同理，进行解锁的时候，也会把上述节点都解锁一遍.
1.8、分布式锁扩展
上面介绍的只是简单的 “互斥锁”.
锁这里还涉及到一些其他情况：
1. 读写锁.
2. 公平锁.
3. 可重入锁
........
基于 redis 也可以实现上述锁的特性，这里大家下来可以自己尝试实现以下~