本文主要是介绍Redis进阶(七):分布式锁,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
在分布式系统下,涉及到多个节点访问同一个公共资源的情况,此时需要通过 锁 进行互斥控制:避免出现 线程安全问题。
1.分布式锁的基本实现
超卖问题:
解决:
采用redis实现分布式锁
可用采取:在购票的时候,操作过程中需要先加锁。在redis上设置一个key - value,完成上述买票操作,再把key - value 删掉。如果发现key - value 存在,就加锁失败,无法进行购票
上述可用保证,第一个服务器执行(查询 - 更新)过程中,第二个服务器不会执行 (查询)操作
具体实现:
redis中的setnx命令(不存在就设置进去,当前key值存在就失败)解锁使用del
考虑一下特殊情况:
某个服务器加锁成功后,在执行后续逻辑的过程中,程序崩溃了,没有执行到解锁操作?
不可以采取finally:这种做法只是针对进程内的锁有用,针对分布式锁无效,比如说服务器直接掉电,进程异常终止,后面的del逻辑都走不到~
还可以使用过期时间来实现~
给set的key设置一个过期时间,时间到了key自动被删去了。
可以使用 set ex nx
异常情况:
这个时候还有一个问题,服务器1给redis上锁,服务器2给解锁了,会引起超卖问题
为了解决上述问题,就需要加入校验机制
1、给服务器编号,每个服务器有自己的身份标识
2、进行加锁的时候,设置key-value。key对应着要针对哪一个资源进行加锁~,value就可以存储刚才服务器的编号~~这样可以表示出,这个锁是哪一个服务器加上的。
因此后续解锁的时候,就可以进行校验了。
1、解锁的时候,先查询一下这个锁对应的服务器编号,然后判定一下这个编号 是否就是 当前执行的解锁的服务器编号。
2、如果是 ,才去执行del,如果不是,则失败
问题:解锁时,查询判定和del是非原子操作
一个服务器内部,这是俩个行为,会出现线程安全问题,可以使用lua脚本实现原子性
但上述还有问题:设置过期时间后,仍然存在一定的可能性,任务没执行完,key先过期了,导致锁提前失效。也就是过期时间的续约问题
这样负责动态续约 专门独立出来的 线程 叫 看门狗
高可用
如果使用redis作为分布式锁,还需要考虑redis挂了的情况,因此要想保证高可用需要一套预案去保证高可用。
搞几个哨兵节点
redlock算法
简而言之:冗余
具体展现为:
这篇关于Redis进阶(七):分布式锁的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!