- Redis分布式锁介绍
1.1分布式锁常见的场景
如果是在同一个jvm的时候可以使用Synchronized或者Lock的方式加锁解决。如果是分布式情况下可以使用分布式锁。
- 分布式锁分析
1.2Redis分布式锁分析
使用setnx lock “123”命令,返回1则表示设置锁成功,返回0则表示被别人锁住了。
但是setnx 和expire2个命令不是原子操作
可以在设置锁同时设置过期时间,则该操作是原子的。
还有个办法使用lua脚本。
蓝色的是lua的表达式,2表示2个参数
如果是3则是3个参数。
redis从3.6开始就内置了lua脚本支持。
这样可以使用lua控制redis的原子性。
2.3Jedis分布式锁实现
也是基于lua的命令分析在Jedis
有5个参数
是个标准的spring boot项目,引入Jedis的jar和测试jar。
加锁实例
锁互斥:一个实例被加锁后别的线程无法获取,只有在该锁过期后才能被获取。
解锁:
1.解锁时必须要判断该锁是否属于自己的锁。
2.在错误实例2中,获取锁和解除锁是2个单独的非原子的操作,应该要在一个原子操作解锁。
怎么保证原子操作?
得使用lua执行,lua执行是串行的原子操作的,这样才能解锁
正确的解锁
这的lua索引是从1开始,不是从0开始。
2.4锁过期问题
锁过期
在图中是进行写文件的锁,随着时间的流逝,锁的操作过程。
实际操作时,一般业务操作预估需要时间10秒,设置锁过期未20秒,但是可能因为java发生gc时可能导致业务操作会超过20秒,等gc完之后锁已经过期了。可能会导致同时2个客户端持有同一个锁,所以导致文件数据混乱。
解决如上问题有2中方案
- 乐观锁增加版本号
为数据增加一个版本号,如果线程在stw完成后此时属于无锁情况下,比对版本号,如果不一致则拒绝写入,尝试重新获取锁。但是使用版本号处理时需要写代码侵入业务。
- watch do 自动延期
这种方案不会侵入代码
- Redisson分布式锁
3.1Redisson简介
有部分功能在reids中使用不太方便的情况下使用Redisson,以及在锁等待过程。这种情况下使用Redisson。
Redisson是基于Netty的Redis客户端。不但能操作原生的Redis数据结构,还为使用者提供了一系列具有分布式特性的常用工具类,实现了分布式锁。
Redisson分布式锁实现
使用RLock对象来加锁,使用lock方法默认是30秒有效,使用trylock可以设置获取锁的超时时间(设置时间内获取不到锁就返回)和设置有效期时间。
锁重入
同一个线程中将对象加锁后,另一个对象去获取当前锁。
redis锁里的hash名字就是锁的名字,key就是线程的uuid,如果重复获取该锁则hash的value则增加1,解锁时获取几次就需要解锁几次。
锁在redis中存储的结构
Redisson分布式锁原理
Redisson是使用lua实现的,整体流程如下,uuid就代表当前线程。
首先会判断锁key是否存在,如果不存在则是新增锁。
如果key存在,则判断当前的字段是不是当前线程的字段(根据uuid)如果不是则返回生存时间,获取锁失败。
如果key存在,并且字段就是当前线程的值,则是锁重入,将value值增加1.
代码如下:类是RedissonLock.java的tryLockINnerAsync方法。
释放锁
释放锁的流程如下,他使用消息发布方式解锁。
keys[2]发布锁的消息的频道名字
判断key是否存在,如果不存在则广播消息。
如果key存在,判断字段存在,将字段值减1,并且判断字段值是否为0,如果是0则发布消息通知其他人该锁已经释放。
如果可以存在,字段存在,子u但减去1.
如果key存在,字段不存在,证明不是自己的锁无法解锁,返回空。
源码位置:
自动延期机制
自动延期是有条件的,条件就是必须使用lock方式(未显示指定时间,默认30秒)有效,如果使用trylock方式是不会自动延期的。
- 分段锁
4.1分段锁的设计
分段锁的需求如下每秒下单600个
根据图中要实现一个订单需要200ms这样每秒只能5个远远达不到,无法达到600个每秒,这时可以使用分段锁来实现。
分段设计:使用map/reduce(ConcurrentHashMap),以空间换时间,将600个商品分成120个段,每段5个。这样可以实现每秒600个。
分段步骤
- 初始化分段锁库存
- 分段锁扣减库存
这样相当于可以允许同时120个段同时进行扣减各自自己的库存,这样可以达到类似并行120来实现。
实现过程如下
可以先抢到分段序号segmentIndex,抢到后扣减本分段序号的库存。
每个程序进来都进行抢分段序号,去抢未被占用的分段序号
分段锁实现
如果不使用分段锁时需要5秒,
如果使用分段锁时,需要的时间为1.8秒左右。