场景1：在单机场景下，可以通过同步锁进行加锁
- 在单机系统下，该场景是适用的，所有的线程都需要等待同步锁释放
场景2：分布式场景下的分布式锁
- 场景1中的代码不适用与分布式系统，因为上述的同步锁是JVM层次的，只能锁住一个分布式中的节点
解决方案
分布式锁适用Redis的setNX【SET if Not eXists】实现，语法如下：
setNX key value
- key：锁的名称
- value：锁对应的值
- 如果Redis中没有该锁，上述语句返回1，加锁成功
- 如果Redis中已有该锁，上述语句返回0，加锁失败
- 解锁：del key
场景3：分布式节点加锁成功，释放锁前宕机如何处理
分布式系统中，节点中线程加锁成功后，在处理业务过程中宕机，分布式锁并没有释放，从而导致死锁问题
解决方案
- 给分布式锁添加过期时间
- 使用setNX的特殊语法格式，如下：
SET key value EX 10 NX
- 设置key的过期时间为10s
- 解锁：del key
场景4：分布式锁过期释放问题
过期时间释放锁问题的原因：
- 过期时间设置的很少
- FULL GC执行时间过长
- 运维手动调整了过期时间
现存问题：
- 分布式中的实例1，加锁成功，在处理业务过程中，锁到期释放，而未执行到释放锁的代码
- 实例2在t3时刻，实例1过期释放锁后，获取分布式锁成功
- 实例1在t4时刻业务代码处理结束，执行释放锁代码，从而导致实例2的锁被释放
- 实例3在实例1释放锁后，重新获取分布式锁
解决方案
1、针对与锁过期问题
- 启动一个异步线程，定时续期（watchdog 看门狗机制）
- 获取锁成功后启动异步线程，每隔x秒对当前的锁续期y秒，直到锁被释放停止
2、针对释放其他线程锁的问题
- 分布式锁的value设置为：唯一的UUID+线程ID
- 当释放锁时，判断分布式锁的value是否与当前一致，一致则释放
- 加锁
SET ${lockName} 唯一的ID值 EX 10 NX
- 解锁：需要使用rua脚本保证Redis操作的原子性
current_value = get ${lockName}
if ${唯一的ID值} == current_value then
DEL ${lockName}
该方案是单机版Redis的分布式系统中，分布式锁的主流解决方案
场景5：Redis集群环境中，主节点加锁未同步备节点问题
现存问题：
- 在sentinel管理的Redis主备集群中，实例1向主节点加锁成功
- 当主节点加锁成功后，未同步至备节点而宕机
- sentinel会从备节点中选择一台备节点作为主节点，从而导致锁丢失
- 锁丢失从而导致锁失效，其他的实例也可以同时访问共享资源
解决方案
- 加锁
- 向所有节点发出加锁请求
- 获取锁成功的数量达到半数以上，才认为加锁成功
- 解锁：删除所有实例上的锁
场景6：Redis集群环境中，网络通信延迟造成的锁过期问题
现存问题：
- 实例1向Redis集群中的3个节点发送加锁请求，锁过期为10s
- 主节点与备节点1s就返回了加锁成功
- 备2节点由于网络延迟，返回花费了11s，此时主节点与备1节点锁已经删除了
解决方案
- 加锁
- 记录 加锁时的当前时间戳t1
- 向所有节点发出加锁请求，为每一个请求设置超时时间（小于锁过期时间ttl），并记录最后收到返回的时间戳t2
- 获取锁成功数量达到半数以上，并且t2-t1 < ttl才认为加锁成功
- 解锁：删除所有实例上的锁
上述方案就是 Redlock
（Redlock 是一种分布式锁的实现算法，是为了在Redis这类分布式键值存储系统中提供一种互斥机制而设计的。它由Redis的创建者Antirez（Salvatore Sanfilippo）提出，用于在分布式系统中安全地执行互斥操作，以确保在任何时候只有一个客户端可以持有锁。）
总结
单机Redis
- 增加过期时间 ：解决应用宕机，锁无法释放的问题
- 增加线程ID，表示锁的归属：解决锁被其他线程释放的问题
- 增加watchdog，为锁自动续期：解决锁被自动清理的问题
集群Redis
- 向所有节点发送加锁请求，半数成功：解决主从切换后的数据不同步问题
- 增加请求超时时间，判断请求时间的消耗：解决网络延迟造成的锁过期问题