最近在看Redisson的源码,用了将近一周的时间终于看完了,现在总结一下比较重要的一些点,如果不够仔细,还请各位指出问题所在,如下是可重入锁的源码总结
1. 创建锁RLock lock = redisson.getLock("mylock");
创建的是RedissonLock
2. lock.lock()或者lock.lock(1000,TimeUnit.SECONDS);
如果传入leasetime也就是上文的1000,则leasetime就是用传入的值,否则默认使用30000ms,也就是30秒
if (leaseTime != -1) {
ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
} else {
ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,
TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
}
3. 选择服务器,创建锁,根据创建的锁名称计算slot(一共有16384个),根据slot确定slot所在的服务器,
RFuture result = executorService.evalWriteAsync(key, codec, evalCommandType, script, keys, params);
NodeSource source = getNodeSource(key);
int slot = connectionManager.calcSlot(key);
4. 调用底层redis lua语句创建锁,判断锁是不是存在,判断是不是当前线程
· "if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
"return redis.call('pttl', KEYS[1]);",
样式如下:
mylock {
uuid:threadId:1
}
5. 创建锁返回值,如果是null则表示创建成功,否则返回锁过期时间ttl(实际是异步的RFuture)
6. 根据是否传入leasetime,如果传入则设置过期时间,如果未设置创建看门狗线程watchdog,是一个timertask,每隔internalLockLeasetime/3也就是10秒执行一次,如果没释放锁,则将锁的过期时间进行续期,续期到30秒
7. 如果创建锁失败(其他线程来创建锁),进入死循环返回锁过期时间,每隔过期时间后,去看一下所有没有释放
while (true) {
ttl = tryAcquire(-1, leaseTime, unit, threadId);
}
最后说一下Redisson的缺点:
因为它是在redis集群中挑选一个master实例来加锁,假设客户端刚刚在master写入一个锁,此时发生了master的宕机,但是master还没来得及将那个锁key异步同步到slave,slave就切换成了新的master。此时别的客户端在新的master上也尝试获取同一个锁,会成功获取锁
此时两个客户端,都会获取同一把分布式锁,可能有的时候就会导致一些数据的问题
redisson的分布式锁,隐患主要就是在这里