目录
什么是分布式锁
在一个分布式系统中,也会涉及到多个节点访问同一个公共资源的情况,此时就需要通过锁来做互斥控制,避免出现类似于"线程安全"的问题.
而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 节点, ⽽要写个多个!! 分布式系统中任何⼀个节点都是不可靠的. 最终的加锁成功结论是 "少数服从多数的".