redis应用-分布式锁

2023-12-13 16:47:13

目录

什么是分布式锁

分布式锁的基本实现

引入过期时间

引入校验id

引入lua

引入看门狗

引入redlock算法


什么是分布式锁

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

而Java中的synchronized这样的锁只能在当前进程中生效,在分布式这样的多个进程多个主机的场景下就无能为力了.

在分布式系统中,有很多进程(每个服务器,都是独立的进程),因此synchronized就难以对现在的分布式系统中的多个进程之间产生制约.

分布式系统中,多个进程之间的执行顺序也是不确定的,充满随机性.

此时就需要分布式锁来控制.

分布式锁本质上是使用一个公共的服务器,来记录加锁状态.这个公共的服务器可以是redis,也可以是其他组件,比如mysql等,还可以是自己写的一个服务.


分布式锁的基本实现

通过一个键值对来表示锁的状态.

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

客户端1先执行查询余票,发现剩余一张,在即将执行1->0的过程之前,客户端2也执行查询余票,查询到的也是剩余一张,客户端2也会执行1->0的过程,就出现了超卖.

显然上述场景存在"线程安全"问题,会出现超卖的情况,需要用锁来控制.

如何进行加锁?

在上述架构中引入一个redis,作为分布式锁的管理器.

此时,如果买票服务器1尝试买票,就需要先访问redis,在redis上设置一个键值对,比如key为车次,value随便设个值,比如1.

如果这个操作设置成功,就视为当前没有节点对该车次加锁,就可以进行数据库的读写操作了,操作完之后,再把redis上刚才的键值对删除掉.

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

redis中提供了setnx操作,正好适合上述场景,key不存在则设置,存在则设置失败.


引入过期时间

当服务器1加锁之后,开始处理买票的过程,如果在此过程中服务器1意外宕机,就会导致后续的解锁操作无法执行,就可能引起其他服务器始终无法获取到锁的情况.

为了解决这个问题,就可以在设置key的同时引入过期时间,即这个锁最多持有多久,就应该被释放.

使用 set ex nx的方式,在设置锁的同时把过期时间也设置进去.此处只能使用一条命令来完成,不能拆分成setnx和expire.


引入校验id

所谓的加锁就是给redis上设置一个key-value,所谓的解锁就是给redis上这个key-value删除掉.

那么也就有可能出现,服务器1执行了加锁,服务器2执行了解锁.

当然服务器2不会进行这样的恶意删除,不过不能保证因为一些bug导致服务器2把锁误删掉.

为了解决上述问题,我们可以引入一个校验id.

比如可以把设置的键值对的值,不在简单的设置为一个而是设置成服务器的编号,形如"001:"服务器1".

这样就可以在删除key的时候,先校验当前删除key的服务器是否是当初加锁的服务器,如果是才能真正的删除,不是则不能删除.

但是很明显,解锁逻辑中的get和del两部操作并非是原子的!!!


引入lua

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

上述情况来说,看起来重复执行DEL好像问题不大?实则不然!!?
主要是引入一个新的服务器,执行加锁就可能出现问题了. .
在线程A执行完DEL之后,B执行DEL之前?
服务器2的线程C正好要执行加锁(set),此时由于A已经把锁释放了,C的加锁是能够成功的!!?
但是紧接着,线程B DEL就到来了.就把刚刚服务器2的加锁操作给解锁了.
服务器1和服务器2进行加锁, key是资源的编号(比如车次),服务器的id是value.

新加的锁被删除了.归根结底是因为get和del不是原子产生的问题.

使用redis的事务可以解决上述问题,但是实践中往往使用更好的方案,lua脚本.

lua是一个变成语言,作为redis内嵌的脚本,lua语言特别轻量.

使?Lua脚本完成上述解锁功能.

上述代码可以编写成?个 .lua 后缀的?件, 由 redis-cli 或者 redis-plus-plus 或者 jedis 等客?端加载, 并发送给 Redis 服务器, 由 Redis 服务器来执?这段逻辑.
?个 lua 脚本会被 Redis 服务器以原?的?式来执?.
redis官方文档也明确说,lua属于是事务的替代方案.

引入看门狗

如果要在加锁的时候,给key设定过期时间.

过期时间设置多少合适呢?

如果设置过短,那么可能业务逻辑没有执行完,锁就被释放了.

如果设置的太长,就会导致锁释放不及时的问题.

更好的方式是动态续约.往往需要服务器这边有一个专门的线程,负责续约,把这个负责的线程就叫做看门狗(watch dog).

初始情况下,设置一个过期的时间(比如设置1s),就提前在还剩比如300ms的时候,如果当前任务还没执行完,就把过期时间在续上1s,等到时间又快到了,任务还没执行完,就在续.

如果服务器,中途崩溃了,自然就没有线程负责续约了,此时,锁也能在较短的时间内被自动释放!!!


引入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 节点, ?要写个多个!! 分布式系统中任何?个节点都是不可靠的. 最终的加锁成功结论是 "少数服从多数的".

文章来源:https://blog.csdn.net/m0_62360856/article/details/134839413
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。