目录第十章 Redis 典型应用 - 分布式锁10.1 什么是分布式锁10.2 分布式锁的基础实现10.3 引入过期时间10.4 引入校验 id10.5 引入lua10.6 引入 watch dog (看门狗)10.7 引入 Redlock 算法10.8 其他功能第十章 Redis 典型应用 - 分布式锁10.1 什么是分布式锁在一个分布式的系统中也会涉及到多个节点访问同一个公共资源的情况。此时就需要通过锁来做互斥控制避免出现类似于线程安全的问题。而java的synchronized或者C的std::mutex这样的锁都是只能在当前进程中生效在分布式的这种多个进程多个主机的场景下就无能为力了。此时就需要使用到分布式锁。本质上就是使用一个公共的服务器来记录 加锁状态。这个公共的服务器可以是Redis也可以是其他组件(比如MySQL或者ZooKeeper等)还可以是我们自己写的一个服务。10.2 分布式锁的基础实现思路非常简单。本质上就是通过一个键值对来标识锁的状态。举个例子考虑买票的场景现在车站提供了若干个车次每个车次的票数都是固定的。现在存在多个服务器节点都可能需要处理这个买票的逻辑先查询指定车次的余票如果余票 0则设置余票值 - 1。显然上述的场景是存在线程安全问题的需要使用锁来控制。否则就可能出现超卖的情况。此时如何进行加锁呢我们可以在上述架构中引入一个Redis作为分布式锁的管理器。此时如果买票服务器1尝试买票就需要先访问Redis在Redis上设置一个键值对。比如key就是车次value随便设置个值(比如1)。如果这个操作设置成功就视为当前没有节点对该001车次加锁就可以进行数据库的读写操作。操作完成之后再把Redis上刚才的这个键值对给删除掉。如果在买票服务器1操作数据库的过程中买票服务器2也想买票也会尝试给Redis上写一个键值对key同样是车次。但是此时设置的时候发现该车次的key已经存在了则认为已经有其他服务器正在持有锁此时服务器2就需要等待或者暂时放弃。Redis中提供了setnx操作正好适合这个场景。即key不存在就设置存在则直接失败。但是上述方案并不完整。10.3 引入过期时间当服务器1加锁之后开始处理买票的过程中如果服务器1意外宕机了就会导致解锁操作(删除该key)不能执行。就可能引起其他服务器始终无法获取到锁的情况。为了解决这个问题可以在设置key的同时引入过期时间。即这个锁最多持有多久就应该被释放。可以使用set ex nx的方式在设置锁的同时把过期时间设置进去。注意此处的过期时间只能使用一个命令的方式设置。如果分开多个操作比如setnx之后再来一个单独的expire由于Redis的多个指令之间不存在关联并且即使使用了事务也不能保证这两个操作都一定成功因此就可能出现setnx成功但是expire失败的情况。此时仍然会出现无法正确释放锁的问题。10.4 引入校验 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这样做并非是原子的。10.5 引入lua为了解锁操作原子可以使用Redis的Lua脚本功能。Lua也是一个编程语言。读作撸啊。是葡萄牙语中的月亮的意思。(出自于Lua官方文档 Lua: about)Lua的语法类似于JS是一个动态弱类型的语言。Lua的解释器一般使用C语言实现。Lua语法简单精炼执行速度快解释器也比较轻量(Lua解释器的可执行程序体积只有200KB左右)。因此Lua经常作为其他程序内部嵌入的脚本语言。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服务器以原子的方式来执行。10.6 引入 watch dog (看门狗)上述方案仍然存在一个重要问题。当我们设置了key过期时间之后(比如10s)仍然存在一定的可能性当任务还没执行完key就先过期了。这就导致锁提前失效。把这个过期时间设置的足够长比如30s是否能解决这个问题呢很明显设置多长时间合适是无止境的。即使设置再长也不能完全保证就没有提前失效的情况。而且如果设置的太长了万一对应的服务器挂了此时其他服务器也不能及时的获取到锁。因此相比于设置一个固定的长时间不如动态的调整时间更合适。所谓watch dog本质上是加锁的服务器上的一个单独的线程通过这个线程来对锁过期时间进行续约。注意这个线程是业务服务器上的不是Redis服务器的。举个具体的例子初始情况下设置过期时间为10s。同时设定看门狗线程每隔3s检测一次。那么当3s时间到的时候看门狗就会判定当前任务是否完成。如果任务已经完成则直接通过lua脚本的方式释放锁(删除key)。如果任务未完成则把过期时间重写设置为10s。(即续约)这样就不担心锁提前失效的问题了。而且另一方面如果该服务器挂了看门狗线程也就随之挂了此时无人续约这个key自然就可以迅速过期让其他服务器能够获取到锁了。10.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节点而要写多个分布式系统中任何一个节点都是不可靠的。最终的加锁成功结论是少数服从多数的。由于一个分布式系统不至于大部分节点都同时出现故障因此这样的可靠性要比单个节点来说靠谱不少。10.8 其他功能上述描述中我们解释了基于Redis的分布式锁的基本实现原理。上述锁只是一个简单的互斥锁。但是实际上我们在一些特定场景中还有一些其他特殊的锁比如可重入锁公平锁读写锁......基于Redis的分布式锁也可以实现上述特性。(当然了对应的实现逻辑也会更复杂)。实际开发中我们也并不会真的自己实现一个分布式锁。已经有很多现成的库帮我们封装好了我们直接使用即可。比如Java中的RedissonC中的redis-plus-plus。当然有些大厂也会有自己版本的分布式锁的实现。
Redis 典型应用 - 分布式锁
目录第十章 Redis 典型应用 - 分布式锁10.1 什么是分布式锁10.2 分布式锁的基础实现10.3 引入过期时间10.4 引入校验 id10.5 引入lua10.6 引入 watch dog (看门狗)10.7 引入 Redlock 算法10.8 其他功能第十章 Redis 典型应用 - 分布式锁10.1 什么是分布式锁在一个分布式的系统中也会涉及到多个节点访问同一个公共资源的情况。此时就需要通过锁来做互斥控制避免出现类似于线程安全的问题。而java的synchronized或者C的std::mutex这样的锁都是只能在当前进程中生效在分布式的这种多个进程多个主机的场景下就无能为力了。此时就需要使用到分布式锁。本质上就是使用一个公共的服务器来记录 加锁状态。这个公共的服务器可以是Redis也可以是其他组件(比如MySQL或者ZooKeeper等)还可以是我们自己写的一个服务。10.2 分布式锁的基础实现思路非常简单。本质上就是通过一个键值对来标识锁的状态。举个例子考虑买票的场景现在车站提供了若干个车次每个车次的票数都是固定的。现在存在多个服务器节点都可能需要处理这个买票的逻辑先查询指定车次的余票如果余票 0则设置余票值 - 1。显然上述的场景是存在线程安全问题的需要使用锁来控制。否则就可能出现超卖的情况。此时如何进行加锁呢我们可以在上述架构中引入一个Redis作为分布式锁的管理器。此时如果买票服务器1尝试买票就需要先访问Redis在Redis上设置一个键值对。比如key就是车次value随便设置个值(比如1)。如果这个操作设置成功就视为当前没有节点对该001车次加锁就可以进行数据库的读写操作。操作完成之后再把Redis上刚才的这个键值对给删除掉。如果在买票服务器1操作数据库的过程中买票服务器2也想买票也会尝试给Redis上写一个键值对key同样是车次。但是此时设置的时候发现该车次的key已经存在了则认为已经有其他服务器正在持有锁此时服务器2就需要等待或者暂时放弃。Redis中提供了setnx操作正好适合这个场景。即key不存在就设置存在则直接失败。但是上述方案并不完整。10.3 引入过期时间当服务器1加锁之后开始处理买票的过程中如果服务器1意外宕机了就会导致解锁操作(删除该key)不能执行。就可能引起其他服务器始终无法获取到锁的情况。为了解决这个问题可以在设置key的同时引入过期时间。即这个锁最多持有多久就应该被释放。可以使用set ex nx的方式在设置锁的同时把过期时间设置进去。注意此处的过期时间只能使用一个命令的方式设置。如果分开多个操作比如setnx之后再来一个单独的expire由于Redis的多个指令之间不存在关联并且即使使用了事务也不能保证这两个操作都一定成功因此就可能出现setnx成功但是expire失败的情况。此时仍然会出现无法正确释放锁的问题。10.4 引入校验 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这样做并非是原子的。10.5 引入lua为了解锁操作原子可以使用Redis的Lua脚本功能。Lua也是一个编程语言。读作撸啊。是葡萄牙语中的月亮的意思。(出自于Lua官方文档 Lua: about)Lua的语法类似于JS是一个动态弱类型的语言。Lua的解释器一般使用C语言实现。Lua语法简单精炼执行速度快解释器也比较轻量(Lua解释器的可执行程序体积只有200KB左右)。因此Lua经常作为其他程序内部嵌入的脚本语言。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服务器以原子的方式来执行。10.6 引入 watch dog (看门狗)上述方案仍然存在一个重要问题。当我们设置了key过期时间之后(比如10s)仍然存在一定的可能性当任务还没执行完key就先过期了。这就导致锁提前失效。把这个过期时间设置的足够长比如30s是否能解决这个问题呢很明显设置多长时间合适是无止境的。即使设置再长也不能完全保证就没有提前失效的情况。而且如果设置的太长了万一对应的服务器挂了此时其他服务器也不能及时的获取到锁。因此相比于设置一个固定的长时间不如动态的调整时间更合适。所谓watch dog本质上是加锁的服务器上的一个单独的线程通过这个线程来对锁过期时间进行续约。注意这个线程是业务服务器上的不是Redis服务器的。举个具体的例子初始情况下设置过期时间为10s。同时设定看门狗线程每隔3s检测一次。那么当3s时间到的时候看门狗就会判定当前任务是否完成。如果任务已经完成则直接通过lua脚本的方式释放锁(删除key)。如果任务未完成则把过期时间重写设置为10s。(即续约)这样就不担心锁提前失效的问题了。而且另一方面如果该服务器挂了看门狗线程也就随之挂了此时无人续约这个key自然就可以迅速过期让其他服务器能够获取到锁了。10.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节点而要写多个分布式系统中任何一个节点都是不可靠的。最终的加锁成功结论是少数服从多数的。由于一个分布式系统不至于大部分节点都同时出现故障因此这样的可靠性要比单个节点来说靠谱不少。10.8 其他功能上述描述中我们解释了基于Redis的分布式锁的基本实现原理。上述锁只是一个简单的互斥锁。但是实际上我们在一些特定场景中还有一些其他特殊的锁比如可重入锁公平锁读写锁......基于Redis的分布式锁也可以实现上述特性。(当然了对应的实现逻辑也会更复杂)。实际开发中我们也并不会真的自己实现一个分布式锁。已经有很多现成的库帮我们封装好了我们直接使用即可。比如Java中的RedissonC中的redis-plus-plus。当然有些大厂也会有自己版本的分布式锁的实现。
