| title |
|---|
如何设计一个 Redis 分布式锁？ |
作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学
多线程并发在我们做系统架构设计中经常遇到，例如：抽奖、秒杀、库存 等。
面对多个请求同时对一个共享资源 修改，如何保证数据安全，这里就需要引入 锁 来解决临界资源的访问安全。
JDK 中提供了 synchronized 和 Lock 两种锁。
无论哪一种锁，有一个前提条件，都是解决同一个 JVM 进程下的线程安全问题。
面对当下分布式微服务系统架构，多个系统，多台机器，多个进程，JDK 提供的锁已经无法解决这个问题。
这时，我们需要一个分布式锁
在实现 JVM 锁时，我们将锁的状态保存在 Java 的对象头中，分布式锁也是类似的道理，将锁的状态保存在一个外部存储，比如：MySQL、Redis 等存储服务中。
1、互斥性，这个是锁的最基本要求 2、可重入性，同一个线程可以重复多次获得锁 3、支持阻塞、非阻塞两种特性 4、支持锁超时，为了防止线程意外退出，没有正常释放锁，导致其他线程无法正常获取到锁。加锁时间超过一定时间，会自动释放锁
加锁通常使用 set 命令来实现，伪代码如下
set key value PX milliseconds NX
参数说明：
- key、value：键值对；
- PX milliseconds：设置键的过期时间为 milliseconds 毫秒；
- NX：只在键不存在时，才对键进行设置操作。SET key value NX 效果等同于 SETNX key value；
- PX、expireTime：用于解决没有解锁导致的死锁问题。因为如果没有过期时间，万一程序员写的代码有 bug 导致没有解锁操作，则就出现了死锁，因此该参数起到了一个“兜底”的作用；
Spring Data Redis 已经帮我们封装好了现成的方法，拿来开箱直接使用即可。代码如下：
首次加锁，Redis 中 key 是空的，键值对关联成功后，调用结果返回 True，表示加锁成功。
为了防止一些特殊情况出现，导致锁没有正常释放，这里为 Key 设置了一个过期时间，作为一个兜底策略，超时锁会自动释放
删除key，表示释放分布式锁。
简单几行代码，就可以实现一个分布式锁，感觉也没什么复杂的。
根据二八原则，80% 的时间都花费在少数几件重要的事情上。我们做系统开发也是一样道理，功能编码可能只需要几天时间，但是优化其中的性能、稳定性、高可用 等可能要花上一周甚至更长时间。
那我们看看上面的方案有没有瑕疵呢？
加锁和解锁这种通用性操作一般都是以公共组件形式存在，比如封装成一个工具类方法，供上层业务直接调用，避免重复建设。
这就带来一个问题，如果一个新同学没有调用 lock() 方法，上来直接先调用了 unLock() 方法，此时会将别人的锁释放掉，引发数据安全问题。
为了解决这个问题，我们要求哪个线程加的锁，同样必须那个线程才能释放锁。
如何才能达到加锁和释放锁绑定到同一个线程呢？
这里提供了一个简单思路
- 我们在加锁的时候，会将线程的 id 编号存到 Redis 缓存中，预埋了个线索
- 我们释放锁时，需再次传入线程 id，比较操作的 key 是否归属于这个线程 id
- 如果匹配成功，才能执行删除操作
释放锁有多个操作，为了保证操作的原子性，这里采用 Lua 脚本
演示代码：
现在貌似加锁 和释放锁 基本能满足需求，但是一个方法内部调用逻辑通常是复杂的。
如果上层已经获得了锁，那后面的方法对同一个 key 将无法再次获得锁了，我们要考虑锁的可重入性。
为了便于理解，画了个流程图，在第四步内部业务逻辑处理完后，会把锁释放了。
这时，回到最外层第六步，再释放锁时，已经没有锁可以释放了，虽然删除本身具有幂等性。
但这个期间，由于锁已经被内部方法早早的释放了，其他线程就可以重新拿到锁，从而导致数据安全问题。
参考 ReentrantLock 锁的可重入性设计思路，在加锁、释放锁的方法中加入计数器
- 首先，查询 key1 关联的值
- 如果为空，说明该线程能拿到锁，将 value 值关联到 key1 上
- 同时，定义了一个计数器 key2，将其关联的数值 加 1 ，初始为空，默认为 0
- 最后，将 key1、key2 设置过期时间
释放锁时，除了比较 线程标识 来判断是否当前线程持有的锁外，还增加了一些逻辑
对锁计数器减一，当值变为0时，对分布式锁的 key 做清理动作
结果描述：
返回 1，表示解锁成功。返回 0，表示解锁失败，不是自己的锁
Number count = redisTemplate.execute(RedisScriptConfig.getReentrantScript(), keys, value, 30);
上面提供的都是非阻塞锁 ，不管是否能获取锁，都会立即返回。
对于阻塞锁，我们可以参考 JUC 并发包的 Atomic 实现方式，采用自旋锁
