自学内容网 自学内容网

[Redis]典型应用——分布式锁

什么是分布式锁?

在一个分布式系统中,也会涉及到多个节点访问同一个公共资源的情况。此时就需要通过锁来做互斥控制,避免出现类似于"线程安全"的问题

举个例子,在平时抢票时,多个用户可能会同时买票,但票数有限,现在存在多个服务器节点,都可能需要处理这个买票的逻辑:先查询指定车次的余票,如果余票>0,则设置余票值-=1 。显然,这样的情况是存在线程安全问题的,如果不加锁控制,就会导致超卖或数据错误。但是,这可能涉及到不同的机器,而不是传统的同一个线程可以加锁,不同的机器间怎么保证线程安全呢?

为了解决上述问题,我们就可以把redis作为架构中分布式锁的管理器。

分布式锁本质上就是一个架构内一台公共的服务器,用来记录加锁状态,而redis就可以完成这样的工作

工作原理 

 为了防止出现线程安全问题,我们可以在服务器操作数据库之前要先访问redis,在redis上设置一个键值对(mutex:1),如果设置成功,视为获取锁成功,就可以对数据库操作,操作完后,就把redis对应的数据删掉,视为释放锁。在这期间,如果其他服务器想操作数据库,也必须先设置同样的key,设置失败就不能访问数据库。

引入过期时间

但是上述方案还是有问题,如果设置key后,服务器宕机了怎么办?锁就永远无法释放了,所以我们就要设置key的过期时间

服务器在设置key的时候,同时设置key的过期事件,也就是说这个锁最多持有多久,过期自动释放。

注意!此处的过期时间只能使用一个命令的方式设置

如果分开多个操作,比如setnx之后,再来一个单独的expire,由于Redis的多个指令之间不存在关 联,并且即使使用了事务也不能保证这两个操作都一定成功,因此就可能出现setnx成功,但是expire 失败的情况

此时仍然会出现无法正确释放锁的问题

 引入校验id

有没有可能自己设置的锁被别人释放了呢?请看下图

可能会因为一些潜在bug或误操作,释放了别人设置的锁,就会发生很大的问题

为了解决这个问题,我们可以引入校验id

 也就是设置key时设置的value改成有意义的能表示身份的值,比如可以把客户端编号,几号客户端设置的key就把value设置成几

这样,在释放锁,也就是删除key的时候,先校验删除的key的value是不是对应当初加锁的值,如果是,再删数据

引入lua

但是上面这个操作中,先get key再del key 这两步并不是原子的,也会有线程安全问题。

为了让解锁操作原子性,可以使用redis的lua脚本功能

Lua也是一个编程语言.读作"撸啊"。是葡萄牙语中的"月亮"的意思

为什么redis会选择lua作为内嵌的脚本语言呢?因为Lua语法简单精炼,执行速度快,解释器也比较轻量,内嵌到redis中不会太过于臃肿

lua脚本可以编写成一个.lua后缀的文件,可以由 redis-cli 发送给redis,由redis服务器来执行脚本

一个lua脚本会被redis服务器以原子的方式执行

引入看门狗(watch dog)

上述方案仍然有一定问题,当我们设置过期时间(比如10s)后,如果任务还没有执行完,锁就已经过期失效了,怎么办?

那就可以引入看门狗,本质上是服务器上的一个单独的线程,通过这个线程来对锁过期时间进行"续约"

比如说,我们设置10s过期,设置看门狗每隔3s检测一次,每过3s,看门狗就去判定当前任务是否完成,如果任务完成了,就释放锁,如果任务未完成,就把过期时间重新设置成10s(续约)

值得一提的是,看门狗线程应该是业务服务器的线程,而不是redis服务器的线程

这样,不用担心锁提前过期,就算服务器挂了,看门狗线程也就挂了,就没人去续约,过期就会释放锁了

引入redlock算法

到这里,方案还是有一定问题,如果redis服务器(也就是分布式锁管理器)挂了,怎么办?那我们可以对redis服务器设计主从架构,保证redis服务器的可用性

那么就有一个问题,如果当我获取锁之后,redis主服务器挂了,从服务器变成了主服务器,但是加锁的数据还没有同步,这时候获取的锁失效了,别的服务器仍然可以获取锁

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

我们引入一组Redis节点,其中每一组Redis节点都包含一个主节点和若干从节点.并且组和组之间存储的数据都是一致的,相互之间是"备份"关系

首先,获取锁

客户端依次向Redis 节点(通常是 5 个)请求加锁。每个节点使用相同的 key 和一个唯一的随机值(UUID)(校验用)。

客户端在每个节点上设置锁的过期时间(TTL),以防止锁的持有者崩溃后锁无法释放。

如果客户端无法在某个节点上设置锁(例如,实例不可用或已经被其他客户端持有锁),则立即尝试下一个节点。

其次,检查锁的有效性

客户端计算从开始尝试加锁到完成加锁操作的总时间。

如果总时间小于锁的 TTL ,且客户端至少在 N/2 + 1 个节点上成功加锁,则认为锁获取成功。如果锁获取失败(未能在足够多的节点上成功加锁),客户端应立即在所有节点上释放已获取的锁。

比如说锁过期时间为50ms,有5个redis节点,从给第一个节点加锁开始算,到最后一个节点加锁截止,如果加起来总时间小于锁的过期时间(50ms),而且至少有3个节点加锁成功,那么就获取一个锁成功(50ms)

因为如果加锁流程时间太长,比如锁过期时间是50ms,结果光去各个节点加锁就用了100ms,那肯定有部分锁都已经过期了,这时候也就不能认为加锁成功了 

最后,释放锁

客户端在所有实例上依次释放锁。释放锁时,客户端需要检查锁的值是否与自己持有的随机值一致,以确保只有持有锁的客户端才能释放锁。


原文地址:https://blog.csdn.net/a_zhee1/article/details/140552137

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!