在多台服务时不能使用synchronized
,原因是多台服务之间会失效,需要用到Redis的分布式锁。
可以利用Redis的setnx命令来实现分布式的加锁,但无法保证原子性,是因为要在setnx之后在加上锁的过期时间,这是俩条命令,需要放到一条命令中来保证原子性。
Redis本身没有事务,但可以通过一些命令来完成类似于事务的方式,但无法回滚。
推荐使用set lock value NX EX 10
。解读:lock锁的名称,也就是key,value:lock的值(也就是资源),NX标识表示互斥,EX后加过期时间。
加过期时间是为了防止死锁的出现。例如出现:业务超时,服务宕机等情况。
在释放锁是直接DEL key(锁的名字)即可。
问题解析:当给分布式锁设置了一个过期时间,但业务执行时间比较长,锁在业务执行时释放了,就无法保证业务执行的原子性了。锁设置的过期时间不能太长也不能太短。
解决方案:
.getLock("锁")获取锁
.tryLock(获取锁的最大等待时间,单位)尝试获取锁
.unlock()释放锁
实现,可以说对Redis的分布式锁做了优化redisClient.getLock("锁").tryLock(重试时间,时间单位)获取锁
Redisson的加锁、设置过期时间等操作基于lua脚本完成(保证多条Redis命令的原子性)
releaseTime
(默认30秒)/3的时间做一次续期,增加线程持有锁的时间.tryLock
设置重试时间,它是可以在高并发的情况,提高分布式锁的使用性能重入:指的是线程不一样,锁一样
redis实现的分布式锁不可重入
redisson实现的分布式锁可以重入,它是根据线程的id和锁名称一起判断的。
java中synchronized、ReentrantLock关键字也是重入的
使用场景:业务负责,锁的粒度小的时候可以使用锁的重入,避免多个锁之间产生死锁的问题。
redisson使用hash结构记录线程id和重入次数。key是锁名称,value是线程id和重入次数。必须保证是同一个线程才会出现锁的重入,不是同一个线程会互斥。
解析:redisson的分布式锁在redis宕机之后,哨兵会重新选举一个主节点,此时一个服务正在对原主节点操作,原主节宕机后没有同步数据,又来一个服务对新主节点操作,它是可以获取到锁的,是因为数据没有同步过来,这时两个服务同时持有一把锁,就会产生脏数据。(redis的整体思想是AP高可用的)
不能保证,但可以使用redisson的红锁(RedLock)来解决,不在一个实例上加锁,在多个实例上加锁(加锁的实例数:redis实例数/2+1),但它的性能低,如果非要保证数据的强一致性,可以在采用cp思想的zookeeper或者Seate的的XA模式来保证强一致性