首先,我们先简单上个简单使用 RReadWriteLock 的 demo:
public class RedissonReadWriteLockDemo {
public static void main(String[] args) {
RedissonClient client = RedissonClientUtil.getClient("");
RReadWriteLock readWriteLock = client.getReadWriteLock("myLock");
RLock readLock = readWriteLock.readLock();
RLock writeLock = readWriteLock.writeLock();
// 场景一:先读锁,后写锁
readLock.lock();
writeLock.lock();
readLock.unlock();
writeLock.unlock();
// 场景二:重复获取读锁
readLock.lock();
readLock.lock();
readLock.unlock();
readLock.unlock();
// 场景三:先写锁,后读锁
writeLock.lock();
readLock.lock();
writeLock.unlock();
readLock.lock();
// 场景四:先写锁,再读锁
writeLock.lock();
writeLock.lock();
writeLock.unlock();
writeLock.unlock();
}
}
读写锁作用:
使用场景: 读写锁主要作用就是做到保证数据的一致性。例如有人在读数据的时候,就应该避免数据被修改,从而保证数据读取前后的一致性,其他的情况一样,例如写读,写写;但是如果是读读就没有必要做到互斥了,因为此时数据不会被修改,多少个人过来读都是一样的,不会影响到数据的一致性。
但是,在平时开发中,读写锁是基本用不上的,因为MySQL自带的 MVCC 机制和锁机制就能保证了数据的原子性、一致性、隔离性和持久性。也就是我们说的ACID。而我们普通的程序或者系统,无非就是对数据库的表数据进行增删改查。
如果我们在程序中自己维护了一套元数据,例如map集合,并且我们的程序是分布式系统,那么就可以利用Redisson提供的分布式读写锁来保证元数据的一致性了。
那么下面我们将分析 redisson 提供的 RReadWriteLock 读写锁是如何做到分布式读写控制的,并且证实一下 RReadWriteLock 提供的作用是否和上面所说的一致,还是说会有点出入。
从上面文章我们也知道,Redisson 提供的公平锁是基于 RedissonLock 做的扩展;但其实不但是公平锁,Redisson 提供的读写锁也是基于 RedissonLcok 上做的扩展:
所以接下来,我们只需要分析读锁和写锁的加锁逻辑和释放锁逻辑;但还有读锁的 wathcdog lua 脚本也是要分析的。因为读锁 watchdog 机制虽然和 RedissonLock 保持的是一致的,但是执行的 lua 脚本的方法却是重写过的。
RedissonReadLock#tryLockInnerAsync:
@Override
<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
internalLockLeaseTime = unit.toMillis(leaseTime);
return evalWriteAsync(getName(), LongCodec.INSTANCE, command,
"local mode = redis.call('hget', KEYS[1], 'mode'); " +
"if (mode == false) then " +
"redis.call('hset', KEYS[1], 'mode', 'read'); " +
"redis.call('hset', KEYS[1], ARGV[2], 1); " +
"redis.call('set', KEYS[2] .. ':1', 1); " +
"redis.call('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"if (mode == 'read') or (mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1) then " +
"local ind = redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"local key = KEYS[2] .. ':' .. ind;" +
"redis.call('set', key, 1); " +
"redis.call('pexpire', key, ARGV[1]); " +
"local remainTime = redis.call('pttl', KEYS[1]); " +
"redis.call('pexpire', KEYS[1], math.max(remainTime, ARGV[1])); " +
"return nil; " +
"end;" +
"return redis.call('pttl', KEYS[1]);",
Arrays.<Object>asList(getName(), getReadWriteTimeoutNamePrefix(threadId)),
internalLockLeaseTime, getLockName(threadId), getWriteLockName(threadId));
}
lua 脚本不长,我们一步一步分析。
Arrays.
KEYS:["myLock","{myLock}:UUID-1:threadId-1:rwlock_timeout"]
internalLockLeaseTime, getLockName(threadId), getWriteLockName(threadId))
internalLockLeaseTime:其实就是 watchdog 的超时时间,默认是30000毫秒,可看 Config#lockWatchdogTimeout。
private long lockWatchdogTimeout = 30 * 1000;
getLockName(threadId):return id + ":" + threadId,客户端ID(UUID):线程ID(threadId)
getWriteLockName(threadId)):super.getLockName(threadId) + ":write"
ARGVS:[30_000毫秒,"UUID-1:threadId-1","UUID-1:threadId-1:write"]
lua脚本
local mode = redis.call('hget', KEYS[1], 'mode');
分析:
hget myLock mode
场景:
lua脚本:
"if (mode == false) then " +
"redis.call('hset', KEYS[1], 'mode', 'read'); " +
"redis.call('hset', KEYS[1], ARGV[2], 1); " +
"redis.call('set', KEYS[2] .. ':1', 1); " +
"redis.call('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
分析:
hset myLock mode read
执行后,锁内容如下:
myLock:{
"mode":"read"
}
hset myLock UUID-1:threadId-1 1
执行后,锁的内容如下:
myLock:{
"mode":"read",
"UUID-1:threadId-1":1
}
set {myLock}:UUID-1:threadId-1:rwlock_timeout:1 1
执行后,redis里读锁的相关数据:
myLock:{
"mode":"read",
"UUID-1:threadId-1":1
}{myLock}:UUID-1:threadId-1:rwlock_timeout:1 1
pexpire {myLock}:UUID-1:threadId-1:rwlock_timeout:1 30000
pexpire myLock 30000
设置锁,还是之前提到的那个点,避免出现死锁的情况。 5. 最后返回nil,表示获取锁成功
场景:
锁模式为读锁,当前线程可获取读锁。即:redisson提供的读写锁支持不同线程重复获取锁
锁模式为写锁,并且获取写锁的线程为当前线程,当前线程可获取读锁。即:redisson 提供的读写锁,读写并不是完全互斥,而是支持同一线程先获取写锁再获取读锁。
关于写锁判断,我们只能到分析获取写锁的lua脚本时再回头看看了;但是我们可以从这里提前知道,如果为写锁添加加锁次数记录,使用的 key 是 UUID-1:threadId-1:write,而读锁使用的 key 是 UUID-1:threadId-1
lua脚本:
"if (mode == 'read') or (mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1) then " +
"local ind = redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"local key = KEYS[2] .. ':' .. ind;" +
"redis.call('set', key, 1); " +
"redis.call('pexpire', key, ARGV[1]); " +
"local remainTime = redis.call('pttl', KEYS[1]); " +
"redis.call('pexpire', KEYS[1], math.max(remainTime, ARGV[1])); " +
"return nil; " +
"end;"
分析:
1 . 利用 hincrby 命令为当前线程增加加锁次数
hincrby myLock UUID-1:threadId-1 1
假设当前线程之前获取过1次锁(假设是读锁),执行后锁内容如下:
myLock:{
"mode":"read",
"UUID-1:threadId-1":2
}
2 . 为当前线程拼接加锁记录 key,然后利用 set 命令添加一条加锁超时记录
key = {myLock}:UUID-1:threadId-1:rwlock_timeout:2
set {myLock}:UUID-1:threadId-1:rwlock_timeout:2 1
执行后,redis里读锁的相关数据:
myLock:{
"mode":"read",
"UUID-1:threadId-1":2
}
{myLock}:UUID-1:threadId-1:rwlock_timeout:1 1
{myLock}:UUID-1:threadId-1:rwlock_timeout:2 1
3 . 给新的加锁超时记录设置过期时间
pexpire {myLock}:UUID-1:threadId-1:rwlock_timeout:2 30000
4 . 最后,pttl 命令获取锁的过期时间,利用 pexipre 给锁重新设置锁的过期时间
pttl myLock
pttl 和 30000 中选出最大值
pexpire myLock 最大值
5 . 最后返回nil,表示获取锁成功
场景:
lua脚本:
"return redis.call('pttl', KEYS[1]);"
分析:
1 . 利用 pttl 命令获取锁过期时间(毫秒)
pttl myLock
2 . 直接返回步骤1的获取到的毫秒数
我们上面提到,虽然 RReadWriteLock 还是延用 RedissonLock watchdog 的机制,但是读锁 对于 watchdog 执行 lua 脚本的方法是进行了重写的,所以我们还是需要分析读锁关于 watchdog lua 脚本的执行逻辑,而后面的写锁就不再需要关注了。
RedissonReadLock#renewExpirationAsync:
@Override
protected RFuture<Boolean> renewExpirationAsync(long threadId) {
String timeoutPrefix = getReadWriteTimeoutNamePrefix(threadId);
String keyPrefix = getKeyPrefix(threadId, timeoutPrefix);
return evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
"local counter = redis.call('hget', KEYS[1], ARGV[2]); " +
"if (counter ~= false) then " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"if (redis.call('hlen', KEYS[1]) > 1) then " +
"local keys = redis.call('hkeys', KEYS[1]); " +
"for n, key in ipairs(keys) do " +
"counter = tonumber(redis.call('hget', KEYS[1], key)); " +
"if type(counter) == 'number' then " +
"for i=counter, 1, -1 do " +
"redis.call('pexpire', KEYS[2] .. ':' .. key .. ':rwlock_timeout:' .. i, ARGV[1]); " +
"end; " +
"end; " +
"end; " +
"end; " +
"return 1; " +
"end; " +
"return 0;",
Arrays.<Object>asList(getName(), keyPrefix),
internalLockLeaseTime, getLockName(threadId));
}
lua 脚本不长,我们一步一步分析。
Arrays.
KEYS:["myLock","{myLock}"]
internalLockLeaseTime, getLockName(threadId)
internalLockLeaseTime:其实就是 watchdog 的超时时间,默认是30000毫秒,可看 Config#lockWatchdogTimeout。
private long lockWatchdogTimeout = 30 * 1000;
getLockName(threadId):return id + ":" + threadId,客户端ID(UUID):线程ID(threadId)
ARGVS:[30_000毫秒,"UUID-1:threadId-1"]
lua脚本
local counter = redis.call('hget', KEYS[1], ARGV[2]);
分析:
1 . 利用 hget 命令获取当前当前线程的加锁次数
hget myLock UUID-1:threadId-1
lua脚本:
"if (counter ~= false) then " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"if (redis.call('hlen', KEYS[1]) > 1) then " +
"local keys = redis.call('hkeys', KEYS[1]); " +
"for n, key in ipairs(keys) do " +
"counter = tonumber(redis.call('hget', KEYS[1], key)); " +
"if type(counter) == 'number' then " +
"for i=counter, 1, -1 do " +
"redis.call('pexpire', KEYS[2] .. ':' .. key .. ':rwlock_timeout:' .. i, ARGV[1]); " +
"end; " +
"end; " +
"end; " +
"end; " +
"return 1; " +
"end; " +
分析:
1 . 利用 pexpire 命令重新刷新锁过期时间
pexpire myLock 30000
2 . 利用 hlen 命令获取锁集合里面的元素个数,然后判断是否大于1个以上key
hlen myLock
做这个判断是因为,如果是可重入锁或者公平锁,锁集合里面只有有一个key,就是当前成功获取锁的线程。但如果是读写锁,他里面可包含2个以上key,其中一个就是锁的模式,即之前提到的 mode 字段,可表示当前锁是读锁还是写锁。
3 . 如果锁集合里面大于1个key,需为每个加锁线程刷新过期时间
hkeys myLock
hget myLock key
每加锁一次
pexpire {myLock}:UUID-1:threadId-1:rwlock:timeout:value 30000
之所以遍历加锁次数,看完上面其实也清楚了。因为每成功加锁一次,redisson 都会为当前线程新增一条加锁记录,并且设置过期时间。所以其实步骤3整体就是为了给所有加锁记录刷新过期时间。
如果key的值为数字,证明此key是加锁成功的线程,并且value的值表示线程加锁次数;我们需要遍历加锁次数我们利用 pexpire 为这个线程对应的加锁记录刷新过期时间
遍历所有key,并利用 hget 命令来获取key对应的value
利用 hkeys 命令获取锁集合里面所有key
4 . 如果步骤3不满足,直接返回1
到此,文章已经介绍了 RedissonReadLock 是如何获取锁的,也分析了 wathchdog 为锁续命的逻辑。关于 RedissonReadLock 如何释放锁,以及 RedissonWriteLock 如何获取锁和释放锁,将继续按照之前的风格,分别写上三篇文章。
本文由哈喽比特于3年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/PQI4t50qXsj3ppjDhBTEmA
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。