并发场景下的锁机制，其实就是用来保护不同线程对共享资源的访问，这样可以确保程序按预设的逻辑执行。 分布式锁也是一样的原理，它是用于分布式系统并发场景下访问共享资源的一种锁机制。
一把合格的分布式锁，应该至少具备以下特征：
- 互斥性：任意时刻，只有一个客户端持有。
- 超时机制：持有锁并超时时，可以自动释放，避免死锁。
- 安全性：在未超时场景下，锁只能被持有者释放。
单节点分分布式锁
SET 是 redis 关键字指令，属于原子操作，其作用是给指定 key 赋值 value。并且支持 NX 和 PX 参数：
- NX：
if not exists缩写，当 key 不存在时才允许赋值成功。 - PX：表示过期时间。
核心语句
SET key uniqueValue NX PX 1000
具体的场景如下：
1、用户一：创建随机值，使用 set 赋值，赋值成功，持有分布式锁。
2、用户二：创建随机值，使用 set 赋值，赋值失败。
3、用户一：执行任务超过1秒，自动释放锁。
4、用户二：创建随机值，使用 set 赋值，赋值成功，持有分布式锁。
5、用户一：任务结束，获取锁，对比当前锁是否属于自己，不属于则忽略。
多节点分布式锁
单节点 redis 可以基于 SET key uniqueValue NX PX 1000 实现分布式锁，但存在宕机的风险。
所以 redis 作者提出了 redlock 算法，用于支持多节点下的分布式锁。
其算法步骤（以5个节点为例）：
1、获取当前时间戳 和 UUID值。
2、基于过期时间选择毫秒级的网络连接和响应时间。
3、客户端逐一去申请锁，申请方式和单节点一样，当从 N/2 + 1 个节点都获取到锁，且使用时间小于当前锁失效时间，才算获取成功。
4、真正的执行时间，时过期时间-获取锁的时间-时钟偏移时间。
5、释放锁时需要每一个节点都尝试释放锁。
👇👇👇
本文作者: Czasg
版权声明: 转载请注明出处哦~👮