分布式锁
随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效。
单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!
分布式锁主流的实现方案:
1. 基于数据库实现分布式锁
2. 基于缓存(Redis等)
3. 基于Zookeeper
每一种分布式锁解决方案都有各自的优缺点:
1. 性能:redis最高
2. 可靠性:zookeeper最高
这里,我们基于 redis setNX 命令实现分布式锁。
基于redis单线程的原理
当线程过来后 进行 setNX <key> <value>操作 只有第一个线程可以设置成功
如第一个线程 setNX key lock,呢只有当一一个线程删掉 key 后后面的线程才能继续执行
同时会出一个个问题:
1.第一个线程设锁后业务报错就不会执行后面的删锁
解决方法: try catch 代码块
在finally 语句块内 写删锁语句
2.第一个线程设锁执行业务逻辑,服务器宕机掉线
解决方法:给锁设置过期时间(设锁的同时设置,不要用两条命令)
通过expire设置过期时间(缺乏原子性:如果在setnx和expire之间出现异常,锁也无法释放)
3.在高并发场景会导致没锁的情况
设置了过期时间但是在过期时间结束业务逻辑没有执行完毕
导致我们设置的锁会被其他请求清除掉
解决方法: 设置UUID
设锁的同时将UUID也与之绑定作为 key 对应的 value
删除锁之前判断当前线程的UUID与锁的UUID是否为同一个 为同一个才能进行删除
4.由于某些不可控原因如(突然的网络卡顿)导致线程判断UUID后执行到删锁已经超过了所设置的过期时间,
同时由于高并发的环境,又有新的请求过来设置了新的锁,但是这个线程因为不可控因素刚刚执行到删锁,导致删掉了我们刚刚设置的锁。
解决方法:保证原子性(同时执行同时失败)
续命锁
redisson 框架 http://t.csdnimg.cn/9ODp9