目录

什么是分布式锁

分布式锁的基本实现

引入过期时间

引入校验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脚本完成上述解锁功能.