redis应用-分布式锁
目录
什么是分布式锁
在一个分布式系统中,也会涉及到多个节点访问同一个公共资源的情况,此时就需要通过锁来做互斥控制,避免出现类似于"线程安全"的问题.
而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脚本完成上述解锁功能.
引入看门狗
如果要在加锁的时候,给key设定过期时间.
过期时间设置多少合适呢?
如果设置过短,那么可能业务逻辑没有执行完,锁就被释放了.
如果设置的太长,就会导致锁释放不及时的问题.
更好的方式是动态续约.往往需要服务器这边有一个专门的线程,负责续约,把这个负责的线程就叫做看门狗(watch dog).
初始情况下,设置一个过期的时间(比如设置1s),就提前在还剩比如300ms的时候,如果当前任务还没执行完,就把过期时间在续上1s,等到时间又快到了,任务还没执行完,就在续.
如果服务器,中途崩溃了,自然就没有线程负责续约了,此时,锁也能在较短的时间内被自动释放!!!
引入redlock算法
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!