redis的应用--分布式锁

redis的应用--分布式锁

• • 一、分布式锁的概念
  • 二、分布式锁的基础实现
  • • 2.1初步实现
    • 2.2引入过期时间
    • 2.3引入校验id
    • 2.4引入lua脚本
    • [2.5引入watch dog（看门狗）](#2.5引入watch dog（看门狗）)
    • 2.6引入Redlock算法
  • 三、分布式锁的种类

一、分布式锁的概念

在⼀个分布式的系统中, 也会涉及到多个节点访问同⼀个公共资源的情况. 此时就需要通过 锁 来做互斥控制, 避免出现类似于 "线程安全" 的问题，而java 的 synchronized 或者 C++ 的 std::mutex, 这样的锁都是只能在当前进程中生效, 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了，此时就需要使⽤到分布式锁。

分布式锁的本质：就是使用一个公共的服务器，来记录加锁状态，这个公共的服务器可以是 Redis，也可以是其他组件(比如 MySQL 或者 ZooKeeper 等)，还可以是我们自己写的⼀个服务

二、分布式锁的基础实现

2.1初步实现

redis分布式锁实现思路：本质上就是通过⼀个键值对来标识锁的状态

举例说明

考虑买票的场景，现在车站提供了若干个车次，每个车次的票数都是固定的，现在存在多个服务器节点, 都可能需要处理这个买票的逻辑: 先查询指定车次的余票, 如果余票 > 0, 则设置余票值 -= 1

显然上述的场景是存在 "线程安全" 问题的, 需要使用锁来控制，否则就可能出现 "超卖" 的情况

此时如何进⾏加锁呢?

1. 客户端访问服务器：可以在服务器上使用线程锁来使客户端访问串行化

2. 服务器访问数据库：我们可以在上述架构中引入⼀个 Redis , 作为分布式锁的管理器

此时，如果买票服务器1尝试买票，就需要先访问 Redis，在Redis上设置⼀个键值对，比如 key 就是车次，value 随便设置个值 (比如 1)，如果这个操作设置成功，就视为当前没有节点对该车次加锁，就可以进⾏数据库的读写操作，操作完成之后, 再把 Redis 上刚才的这个键值对给删除掉

如果在 买票服务器1 操作数据库的过程中, 买票服务器2 也想买票, 也会尝试给 Redis 上写⼀个键值对, key 同样是车次. 但是此时设置的时候发现该车次的 key 已经存在了, 则认为已经有其他服务器正在持有锁, 此时 服务器2 就需要等待或者暂时放弃

Redis 中提供了 setnx 操作, 正好适合这个场景. 即: key 不存在就设置, 存在则直接失败

2.2引入过期时间

考虑服务器宕机的情况，就可以发现上述的实现方式存在很大的问题，就是没有人解锁。这时就会导致其他服务器一直无法访问到数据库。这时我们就可以给加的锁设置一个过期时间，如果时间到了那么就进行解锁，这样就不怕加锁的服务器挂了，没人解锁的情况了。

过期时间的设置方法

可以使用set ex set nx的方式，在设置锁的时候将过期时间设置进去

set ex 或 set nx

注意：此处的过期时间只能使用⼀个命令的方式设置，如果分开多个操作，⽐如 setnx 之后，再来⼀个单独的 expire，由于 Redis 的多个指令之间不存在关联，并且即使使用了事务也不能保证这两个操作都⼀定成功，因此就可能出现 setnx 成功，但是 expire 失败的情况

2.3引入校验id

对于 Redis 中写⼊的加锁键值对，其他的节点也是可以删除的，比如 服务器1 写⼊⼀个 "001": 1 这样的键值对，服务器2是完全可以把 "001" 给删除掉的。当然，服务器2 不会进行这样的 "恶意删除" 操作，不过不能保证因为⼀些 bug 导致服务器2把锁误删除

为了解决上述的问题，可以引入一个校验id

比如可以把设置的键值对的值, 不再是简单的设为⼀个 1, 而是设成服务器的编号. 形如 "001": "服务器1" ，这样就可以在删除 key (解锁)的时候, 先校验当前删除 key 的服务器是否是当初加锁的服务器, 如果是, 才能真正删除; 不是, 则不能删除，逻辑用如下伪代码表示：

string key = [要加锁的资源 id];
string serverId = [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");
// 执⾏各种业务逻辑, ⽐如修改数据库数据.
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配.
if (redis.get(key) == serverId) {
redis.del(key);
}

但是很明显, 解锁逻辑是两步操作 "get" 和 "del", 这样做并非是原子的，此时就可以使用redis内嵌的lua脚本来完成该操作

2.4引入lua脚本

为了使解锁操作原子, 可以使用Redis 的 Lua 脚本功能

什么是lua脚本？

Lua 的语法类似于 JS，是⼀个动态弱类型的语言。Lua 的解释器⼀般使⽤ C 语⾔实现，Lua 语法简单精炼，执行速度快，解释器也⽐较轻量(Lua 解释器的可执行程序体积只有 200KB 左右)，因此 Lua 经常作为其他程序内部嵌⼊的脚本语言。Redis 本身就支持 Lua 作为内嵌脚本。Lua 除了和 Redis 搭伙之外, 在很多场景也会作为内嵌脚本. ⽐如在游戏开发领域常常作为编写逻辑的语⾔（魔兽世界，大话西游）

使⽤ 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 服务器以原⼦的⽅式来执⾏

2.5引入watch dog（看门狗）

上述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s)，仍然存在⼀定的可能性，当任务还没执⾏完，key 就先过期了，这就导致锁提前失效

把锁过期时间加长，还会导致锁提前过期吗？

把这个过期时间设置的足够长, 比如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是无止境的. 即使设置再长, 也不能完全保证就没有提前失效的情况. 而且如果设置的太长了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁. 因此相比于设置⼀个固定的长时间, 不如动态的调整时间更合适

什么是watch dog？

所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程，通过这个线程来对锁过期时间进行 "续约"，这个线程是业务服务器上的，不是 Redis 服务器上的

举例说明

初始情况下设置过期时间为 10s. 同时设定看门狗线程每隔 3s 检测⼀次，那么当 3s 时间到的时候，看⻔狗就会判定当前任务是否完成，如果任务已经完成, 则直接通过 lua 脚本的⽅式, 释放锁(删除 key)，如果任务未完成, 则把过期时间重写设置为 10s. (即 "续约")

这样就不担心锁提前失效的问题了.而且另⼀方⾯, 如果该服务器挂了, 看⻔狗线程也就随之挂了, 此时无⼈续约, 这个 key ⾃然就可以迅速过期, 让其他服务器能够获取到锁了

2.6引入Redlock算法

实践中的 Redis ⼀般是以集群的⽅式部署的 (至少是主从的形式, ⽽不是单机). 那么就可能出现以下比较极端的情况:

服务器1 向 master 节点进行加锁操作. 这个写⼊ key 的过程刚刚完成, master 挂了; slave 节点升级成了新的 master 节点. 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave 呢, 此时就相当于 服务器1 的加锁操作形同虚设了, 服务器2 仍然可以进⾏加锁 (即给新的 master 写⼊ key. 因为新的 master 不包含刚才的 key)

为了解决这个问题, Redis 的作者提出了 Redlock 算法

Redlock算法的原理

我们引⼊⼀组 Redis 节点，其中每⼀组 Redis 节点都包含⼀个主节点和若干从节点，并且组和组之间存储的数据都是⼀致的，相互之间是 "备份" 关系(而并非是数据集合的⼀部分，这点有别于 Redis cluster).

加锁的时候, 按照⼀定的顺序，写多个 master 节点， 在写锁的时候需要设定操作的 "超时时间"，比如 50ms. 即如果 setnx 操作超过了 50ms 还没有成功，就视为加锁失败，如果给某个节点加锁失败, 就⽴即再尝试下⼀个节点，当加锁成功的节点数超过总节点数的⼀半, 才视为加锁成功

如上图, ⼀共五个节点, 三个加锁成功, 两个失败, 此时视为加锁成功，这样的话, 即使有某些节点挂了, 也不影响锁的正确性

是否可能出现所有主节点都挂了的情况呢？

理论上这件事是可能发生的, 但是概率太小了. 工程上就可以忽略不计了

同理, 释放锁的时候, 也需要把所有节点都进行解锁操作. (即使是之前超时的节点, 也要尝试解锁, 尽量保证逻辑严密)，简而言之, Redlock 算法的核心就是，加锁操作不能只写给⼀个 Redis 节点, 而要写个多个!! 分布式系统中任何⼀个节点都是不可靠的. 最终的加锁成功结论是 "少数服从多数的". 由于⼀个分布式系统不至于大部分节点都同时出现故障, 因此这样的可靠性要比单个节点来说靠谱不少

三、分布式锁的种类

上述描述中我们解释了基于 Redis 的分布式锁的基本实现原理，上述锁只是⼀个简单的互斥锁，但是实际上我们在⼀些特定场景中, 还有⼀些其他特殊的锁, 比如:

1. 可重入锁
2. 公平锁
3. 读写锁
4. ...

基于 Redis 的分布式锁, 也可以实现上述特性. (当然了对应的实现逻辑也会更复杂)，实际开发中, 我们也并不会真的自己实现⼀个分布式锁. 已经有很多现成的库帮我们封装好了, 我们直接使用即可，比如Java 中的 Redisson, C++ 中的 redis-plus-plus