Redis分布式锁
分布式锁是什么
锁我们可以理解为对某项资源使用权限的管理,通常使用锁来控制共享资源,比如一个进程内多个线程竞争一个资源的使用权限,解决方式其中就含有加锁。
而分布式锁,就是分布式场景下的锁,多台不同的机器上的进程去竞争同一个资源,需要加分布式锁。
分布式锁的特性
1.互斥性:只让一个竞争者持有锁
2.安全性:避免锁因为异常永久不被释放,使用过期时间兜底
3.对称性:同一个锁,必须由同一个竞争者加锁和释放锁
4.可靠性:一定程度的异常处理能力、容灾能力
Redis实现分布式锁
版本一:easy版本
- setnx key value
利用Redis的setnx命令,将key设置为value,并且返回1;如果key存在,不会创建锁,返回0
流程:通过setnx加锁,加锁之后其他服务无法加锁,用完之后再通过delete解锁
版本二:支持过期时间
如果获取锁的服务挂了,那么锁就一直不被释放,后面的服务无法获取被锁着的资源,所以我们加一个超时时间来兜底。
使用Redis命令,给键加上过期时间即可。
set key value nx ex seconds
ex:增加了过期时间,seconds:设置的过期时间是多久
但是这又有一个新的问题,如果服务A的业务时间比较长,此时锁过期后,服务B获取了锁,然后服务A业务结束后释放了该锁(服务B业务此时还没结束)。
基于这个场景,我们又可以进一步优化分布式锁。
版本三:支持owner
分布式锁需要满足,谁申请的锁谁释放的原则。
同样的,使用Redis命令:set key 业务id nx ex second
在释放锁前,get锁进行判断即可。
另一个方法,也可以启动一个看门狗(go启动一个 gorountine),过期前去刷新过期时间即可。
版本四:lua
其实完整的流程是对的,但是现在还有一个问题:原子性
检查锁,再释放锁,这些操作不是原子的;可能锁获取时还是自己的,删除时已经是别人的了(比如你持有的锁过期了,被别人获取到了)。
使用Redis特性,整合原子操作的lua;Redis+Lua,可以专门解决原子性问题。
有了Lua,Redis才能真正的在分布式锁场景下被使用。
到了版本四,我们已经满足了分布式锁的前三个特性:对称性、安全性、互斥性。
可靠性如何保证
之前都是基于单机的,但是如果Redis挂了,那么就不能获取锁了。
解决方法:主从容灾和多级部署
主从容灾
给Redis配置从节点,当主节点挂掉,可以用从节点暂时顶包。
但是主从切换需要人工参与,提高了人力成本。但是Redis已经有了解决方案,使用哨兵模式,节点灵活自动切换,不需要人工参与。
尽管这种方法一定的程度上解决了单点的容灾问题,但是由于同步时延,Slave会损失部分数据,分布式锁可能会失效,可能会导致短暂的多个机器获取到执行权限。
所以有一个更可靠的办法。
多机部署
对一致性要求更高可以使用多机部署,使用Redis的RedLock。
大概的思路是:通常是N个机器(N一般为奇数),达到一半以上同意加锁才算加锁成功。
加锁流程一般为(以N=5为例):
1.向5个Redis申请加锁
2.超过一半(3个)同意,就可以获取到锁;反之,向每个Redis发送解锁命令
3.由于向5个Redis发送请求,会有一定的时耗,所以锁持有时间应该需要减去请求时间。如果剩余时间为0,那就是获取锁失败
4.使用完锁后,向5个Redis发送解锁请求
这种方案是一般比较成熟的方法了,最后我们再给每个Redis配上哨兵模式就增强了可靠性。
但是这就一定能保证可靠性吗?
不足分析
NPC问题
1.网络时延(Network Delay):RedLock的锁剩余持有时间,需要减去请求时间,可以一定程度的解决网络延迟问题。
2.进程暂停(Process Pause):如果进程获取锁后发生了GC,但是锁已经过期了,那么就会有两个进程获取到同一个锁。
3.时钟漂移(Clock Drift):如果服务A通过RedLock方案获取了锁,但是机器都发送了时钟漂移,锁瞬间过期了,那么又会有两个进程获取到同一个锁。