文章目录
-
-
-
- [🌍1. 什么是分布式锁？](#🌍1. 什么是分布式锁？)
- [🌍2. 分布式锁的基本实现](#🌍2. 分布式锁的基本实现)
- [🌍3. 引入过期时间](#🌍3. 引入过期时间)
- [🌍4. 引入校验ID](#🌍4. 引入校验ID)
- [🌍5. 引入Lua](#🌍5. 引入Lua)
- [🌍6. 引入看门狗（Watch Dog）](#🌍6. 引入看门狗（Watch Dog）)
- [🌍7. 引入Redlock算法](#🌍7. 引入Redlock算法)
-
-
特此注明 ：
Designed By ：长安城没有风
Version：1.0
Time：2025.10.19
Location：辽宁 · 大连
🌍1. 什么是分布式锁？
在⼀个分布式的系统中，也会涉及到多个节点访问同⼀个公共资源的情况，此时就需要通过 锁 来做互斥控制，避免出现类似于"线程安全"的问题。⽽ java 的 synchronized 锁只能在当前进程中⽣效，在分布式的这种多个进程多个主机的场景下就⽆能为⼒了。此时就需要使⽤到分布式锁。
✍ 分布式锁本质上就是使⽤⼀个公共的服务器，来记录加锁状态。这个公共的服务器可以是 Redis，也可以是其他组件(⽐如 MySQL 或者 ZooKeeper 等)，还可以是我们⾃⼰写的⼀个服务。
🌍2. 分布式锁的基本实现
分布式锁的实现思路⾮常简单，本质上就是通过⼀个键值对来标识锁的状态。
🌰举个例子：思考买票的场景，现在⻋站提供了若⼲个⻋次，每个⻋次的票数都是固定的。现在存在多个服务器节点，都可能需要处理这个买票的逻辑：先查询指定⻋次的余票，如果余票 > 0，则设置余票值 -= 1。显然上述的场景是存在 "线程安全" 问题的，需要使⽤锁来控制。（否则会出现超卖问题）
那么如何进行加锁呢？我们可以在上述架构中引⼊⼀个 Redis，作为分布式锁的管理器。此时，如果 买票服务器1 尝试买票，就需要先访问 Redis，在 Redis 上设置⼀个键值对，假设 key 就是⻋次，value 随便设置个值 (⽐如 1)。如果这个操作设置成功，就视为当前没有节点对该 001 ⻋次加锁，就可以进⾏数据库的读写操作，操作完成之后，再把 Redis 上刚才的这个键值对给删除掉。如果在 买票服务器1 操作数据库的过程中，买票服务器2 也想买票，也会尝试给 Redis 上写⼀个键值对，key 同样是⻋次，但是此时设置的时候发现该⻋次的 key 已经存在了，则认为已经有其他服务器正在持有锁，此时 服务器2 就需要等待或者暂时放弃。
🎉 Redis 中提供了 SETNX 操作，正好适合这个场景，即：key 不存在就设置，存在则直接失败。
🌍3. 引入过期时间
虽然上述⽅案简单的实现了分布式锁功能，但是并不完整，当 服务器1 加锁之后，开始处理买票的过程中，如果 服务器1 意外宕机了，就会导致解锁操作 (删除该key) 不能执⾏，就可能引起其他服务器始终⽆法获取到锁的情况。为了解决这个问题，可以在设置 key 的同时引⼊过期时间，即这个锁最多持有多久，就应该被释放。
🌰可以使用 SET EX NX 命令，设置键值对的同时设置过期时间。
注意：此处的过期时间只能使⽤⼀个命令的⽅式设置
如果分开多个操作，⽐如 setnx 之后，再来⼀个单独的 expire，由于 Redis 的多个指令之间不存在关联，并且即使使⽤了事务也不能保证这两个操作都⼀定成功，因此就可能出现 setnx 成功，但是 expire失败的情况，此时仍然会出现⽆法正确释放锁的问题。
🌍4. 引入校验ID
目前我们的分布式锁并不安全，其他服务器是可以任意删除的，⽐如 服务器1 写⼊⼀个 "001": 1 这样的键值对，服务器2 是完全可以把 "001" 给删除掉的，虽然 服务器2 不会进⾏这样的 "恶意删除" 操作，不过不能保证因为⼀些 bug 导致 服务器2 把锁误删
除。为了解决上述问题，我们可以引⼊⼀个校验 ID：
我们可以把键值对的值不再是简单的设为⼀个 1，⽽是设成服务器的编号，形如 "001": "服务器1"。这样就可以在删除 key (解锁)的时候，先校验当前删除 key 的服务器是否是当初加锁的服务器，如果是，才能真正删除，不是，则不能删除。
lua
String key = [要加锁的资源 id];
String serverId = [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");
// 执⾏各种业务逻辑, ⽐如修改数据库数据.
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配.
if (redis.get(key) == serverId) {
redis.del(key);
}🌍5. 引入Lua
从上面的伪代码中可以看出，解锁逻辑是两步操作 "get" 和 "del"，这样做并⾮是原⼦的。为了使解锁操作原⼦，可以使⽤ Redis 的 Lua 脚本功能。
lua
if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1])
else
return 0
end;上述代码可以编写成⼀个 .lua 后缀的⽂件，由 redis-cli 或者 redis-plus-plus 或者 jedis 等客户端加载，并发送给 Redis 服务器，由 Redis 服务器来执⾏这段逻辑。⼀个 lua 脚本会被 Redis 服务器以原⼦的⽅式来执⾏。
🌍6. 引入看门狗（Watch Dog）
上述⽅案仍然存在⼀个重要问题，当我们设置了 key 过期时间之后 (⽐如 10s)，仍然存在⼀定的可能性，当任务还没执⾏完，key 就先过期了，这就导致锁提前失效。那么把过期时间设置的足够长，比如说30s，能否解决这个问题呢？很明显，设置多⻓时间合适，是⽆⽌境的，即使设置再⻓，也不能完全保证就没有提前失效的情况。⽽且如果设置的太⻓了，万⼀对应的服务器挂了，此时其他服务器也不能及时的获取到锁，因此相⽐于设置⼀个固定的⻓时间，不如动态的调整时间更合适。
所谓 watch dog，本质上是加锁的服务器上的⼀个单独的线程，通过这个线程来对锁过期时间进⾏ "续约"。（这个线程是业务服务器上的，不是 Redis 服务器的。）
❤ 举个具体的例⼦:
初始情况下设置过期时间为 10s，同时设定看⻔狗线程每隔 3s 检测⼀次。
那么当 3s 时间到的时候，看⻔狗就会判定当前任务是否完成：
• 如果任务已经完成，则直接通过 lua 脚本的⽅式，释放锁(删除 key)。
• 如果任务未完成，则把过期时间重写设置为 10s。(即 "续约")
这样就不担⼼锁提前失效的问题了，⽽且另⼀⽅⾯，如果该服务器挂了，看⻔狗线程也就随之挂了，此时⽆⼈续约，这个 key ⾃然就可以迅速过期，让其他服务器能够获取到锁了。
🌍7. 引入Redlock算法
实践中的 Redis ⼀般是以集群的⽅式部署的 (⾄少是主从的形式，⽽不是单机)，那么就可能出现以下⽐较极端的⼤冤种情况:
服务器1 向 master 节点进⾏加锁操作，这个写⼊ key 的过程刚刚完成，master 挂了，slave 节点升级成了新的 master 节点，但是由于刚才写⼊的这个 key 尚未来得及同步给 slave 呢，此时就相当于 服务器1 的加锁操作形同虚设了，服务器2 仍然可以进⾏加锁 (即给新的 master 写⼊ key，因为新的 master 不包含刚才的 key)。为了解决这个问题，Redis 的作者提出了 Redlock 算法。
我们引⼊⼀组 Redis 节点，其中每⼀组 Redis 节点都包含⼀个主节点和若⼲从节点，并且组和组之间存储的数据都是⼀致的，相互之间是 "备份" 关系(⽽并⾮是数据集合的⼀部分，这点有别于 Redis cluster)，加锁的时候，按照⼀定的顺序，写多个 master 节点，在写锁的时候需要设定操作的 "超时时间"，⽐如50ms，即如果 setnx 操作超过了 50ms 还没有成功，就视为加锁失败。如果给某个节点加锁失败，就⽴即再尝试下⼀个节点，当加锁成功的节点数超过总节点数的⼀半，才视为加锁成功。这样的话，即使有某些节点挂了，也不影响锁的正确性。同理，释放锁的时候，也需要把所有节点都进⾏解锁操作(即使是之前超时的节点，也要尝试解锁，尽量保证逻辑严密)。简⽽⾔之，Redlock 算法的核⼼就是，加锁操作不能只写给⼀个 Redis 节点，⽽要写多个！！！分布式系统中任何⼀个节点都是不可靠的，最终的加锁成功结论是 "少数服从多数的"。