前言

前面分析了Redisson可重入锁的原理,主要是通过lua脚本加锁及设置过期时间来保证锁执行的原子性,然后每个线程获取锁会将获取锁的次数+1,释放锁会将当前锁次数-1,如果为0则表示释放锁成功。

可重入原理和JDK中的可重入锁都是一致的。

Redisson公平锁原理

JDK中也有公平锁和非公平锁,所谓公平锁,就是保证客户端获取锁的顺序,跟他们请求获取锁的顺序,是一样的。公平锁需要排队,谁先申请获取这把锁,谁就可以先获取到这把锁,是按照请求的先后顺序来的。

Redisson实现公平锁源码分析

公平锁使用也很简单:

1RLock lock = redisson.getFairLock("anyLock");
2lock.lock();
3lock.unlock();

核心lua脚本代码:

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
internalLockLeaseTime = unit.toMillis(leaseTime); long currentTime = System.currentTimeMillis();
if (command == RedisCommands.EVAL_LONG) {
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
// remove stale threads
"while true do "
+ "local firstThreadId2 = redis.call('lindex', KEYS[2], 0);"
+ "if firstThreadId2 == false then "
+ "break;"
+ "end; "
+ "local timeout = tonumber(redis.call('zscore', KEYS[3], firstThreadId2));"
+ "if timeout <= tonumber(ARGV[4]) then "
+ "redis.call('zrem', KEYS[3], firstThreadId2); "
+ "redis.call('lpop', KEYS[2]); "
+ "else "
+ "break;"
+ "end; "
+ "end;" + "if (redis.call('exists', KEYS[1]) == 0) and ((redis.call('exists', KEYS[2]) == 0) "
+ "or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
"redis.call('lpop', KEYS[2]); " +
"redis.call('zrem', KEYS[3], ARGV[2]); " +
"redis.call('hset', 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; " + "local firstThreadId = redis.call('lindex', KEYS[2], 0); " +
"local ttl; " +
"if firstThreadId ~= false and firstThreadId ~= ARGV[2] then " +
"ttl = tonumber(redis.call('zscore', KEYS[3], firstThreadId)) - tonumber(ARGV[4]);" +
"else "
+ "ttl = redis.call('pttl', KEYS[1]);" +
"end; " + "local timeout = ttl + tonumber(ARGV[3]);" +
"if redis.call('zadd', KEYS[3], timeout, ARGV[2]) == 1 then " +
"redis.call('rpush', KEYS[2], ARGV[2]);" +
"end; " +
"return ttl;",
Arrays.<Object>asList(getName(), threadsQueueName, timeoutSetName),
internalLockLeaseTime, getLockName(threadId), currentTime + threadWaitTime, currentTime);
} throw new IllegalArgumentException();
}

KEYS/ARGV参数分析

KEYS = Arrays.asList(getName(), threadsQueueName, timeoutSetName)

  • KEYS1 = getName() = 锁的名字,“anyLock”
  • KEYS[2] = threadsQueueName = redisson_lock_queue:{anyLock},基于redis的数据结构实现的一个队列
  • KEYS[3] = timeoutSetName = redisson_lock_timeout:{anyLock},基于redis的数据结构实现的一个Set数据集合,有序集合,可以自动按照你给每个数据指定的一个分数(score)来进行排序

ARGV = internalLockLeaseTime, getLockName(threadId), currentTime + threadWaitTime,
currentTime

  • ARGV1 = 30000毫秒
  • ARGV[2] = UUID:threadId
  • ARGV[3] = 当前时间(10:00:00) + 5000毫秒 = 10:00:05
  • ARGV[4] = 当前时间(10:00:00)

模拟不同线程获取锁步骤

  1. 客户端A thread01 10:00:00 获取锁(第一次加锁)
  2. 客户端B thread02 10:00:10 获取锁
  3. 客户端C therad03 10:00:15 获取锁

lua脚本源码分析

客户端A thread01 加锁分析

thread01 在10:00:00 执行加锁逻辑,下面开始一点点分析lua脚本执行代码:

1"while true do "
2+ "local firstThreadId2 = redis.call('lindex', KEYS[2], 0);"
3+ "if firstThreadId2 == false then "
4    + "break;"

lindex redisson_lock_queue:{anyLock} 0,就是从redisson_lock_queue:{anyLock}这个队列中弹出来第一个元素,刚开始,队列是空的,所以什么都获取不到,此时就会直接退出while true死循环

1"if (redis.call('exists', KEYS[1]) == 0) and ((redis.call('exists', KEYS[2]) == 0) "
2+ "or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
3"redis.call('lpop', KEYS[2]); " +
4"redis.call('zrem', KEYS[3], ARGV[2]); " +
5"redis.call('hset', KEYS[1], ARGV[2], 1); " +
6"redis.call('pexpire', KEYS[1], ARGV[1]); " +
7"return nil; " +
8"end; " +

这段代码判断逻辑的意思是:

  1. exists anyLock,锁不存在,也就是没人加锁,刚开始确实是没人加锁的,这个条件肯定是成立的;
  2. 或者是exists redisson_lock_queue:{anyLock},这个队列不存在
  3. 或者是lindex
    redisson_lock_queue:{anyLock} 0,队列的第一个元素是UUID:threadId,或者是这个队列存在,但是排在队头的第一个元素,是当前这个线程

那么这个条件整体就可以成立了
anyLock和队列,都是不存在的,所以这个条件肯定会成立。接着执行if中的具体逻辑:

  • lpop redisson_lock_queue:{anyLock},弹出队列的第一个元素,现在队列是空的,所以什么都不会干
  • zrem redisson_lock_timeout:{anyLock} UUID:threadId,从set集合中删除threadId对应的元素,此时因为这个set集合是空的,所以什么都不会干
  • hset anyLock UUID:threadId_01 1,加锁成功:
    anyLock: {
    "UUID_01:threadId_01": 1
    }
  • pexpire anyLock 30000,将这个锁key的生存时间设置为30000毫秒

返回一个nil,在外层代码中,就会认为是加锁成功,此时就会开启一个watchdog看门狗定时调度的程序,每隔10秒判断一下,当前这个线程是否还对这个锁key持有着锁,如果是,则刷新锁key的生存时间为30000毫秒 (看门狗的具体流程上一篇文章有讲述)

客户端B thread02 加锁分析

此时thread01 已经获取到了锁,如果thread02 在10:00:10分来执行加锁逻辑,具体的代码逻辑是怎样执行的呢?

1"while true do "
2+ "local firstThreadId2 = redis.call('lindex', KEYS[2], 0);"
3+ "if firstThreadId2 == false then "
4    + "break;"

进入while true死循环,lindex redisson_lock_queue:{anyLock} 0,获取队列的第一个元素,此时队列还是空的,所以获取到的是false,直接退出while true死循环

1"if (redis.call('exists', KEYS[1]) == 0) and ((redis.call('exists', KEYS[2]) == 0) "
2+ "or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
3"redis.call('lpop', KEYS[2]); " +
4"redis.call('zrem', KEYS[3], ARGV[2]); " +
5"redis.call('hset', KEYS[1], ARGV[2], 1); " +
6"redis.call('pexpire', KEYS[1], ARGV[1]); " +
7"return nil; " +
8"end; " +

此时anyLock这个锁key已经存在了,说明已经有人加锁了,这个条件首先就肯定不成立了;

接着往下执行,看下另外的逻辑:

1"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
2    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
3    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
4    "return nil; " +
5"end; " +

判断一下,此时这个第二个客户端是UUID_02,threadId_02,此时会判断一下,hexists anyLock
UUID_02:threadId_02,判断一下在anyLock这个map中,是否存在UUID_02:threadId_02这个key?这个条件也不成立

继续执行后续代码:

 1"local firstThreadId = redis.call('lindex', KEYS[2], 0); " +
2"local ttl; " + 
3"if firstThreadId ~= false and firstThreadId ~= ARGV[2] then " + 
4    "ttl = tonumber(redis.call('zscore', KEYS[3], firstThreadId)) - tonumber(ARGV[4]);" + 
5"else "
6  + "ttl = redis.call('pttl', KEYS[1]);" + 
7"end; " + 
8
9"local timeout = ttl + tonumber(ARGV[3]);" + 
10"if redis.call('zadd', KEYS[3], timeout, ARGV[2]) == 1 then " +
11    "redis.call('rpush', KEYS[2], ARGV[2]);" +
12"end; " +
13"return ttl;", 

tonumber() 是lua中自带的函数,tonumber会尝试将它的参数转换为数字。

lindex redisson_lock_queue:{anyLock} 0,从队列中获取第一个元素,此时队列是空的,所以什么都不会有

因为我们是在10:00:10 分请求的,因为anyLock默认过期时间是30s,所以在thread02请求的时候ttl还剩下20s

ttl = pttl anyLock = 20000毫秒,获取anyLock剩余的生存时间,ttl假设这里就被设置为了20000毫秒

timeout = ttl + 当前时间 + 5000毫秒 = 20000毫秒 + 10:00:00 + 5000毫秒 = 10:00:25

接着执行:
zadd redisson_lock_timeout:{anyLock} 10:00:25 UUID_02:threadId_02

在set集合中插入一个元素,元素的值是UUID_02:threadId_02,他对应的分数是10:00:25(会用这个时间的long型的一个时间戳来表示这个时间,时间越靠后,时间戳就越大),sorted set,有序set集合,他会自动根据你插入的元素的分数从小到大来进行排序

继续执行:
rpush redisson_lock_queue:{anyLock} UUID_02:theadId_02

这个指令就是将UUID_02:threadId_02,插入到队列的头部去

返回的是ttl,也就是anyLock剩余的生存时间,如果拿到的返回值是ttl是一个数字的话,那么此时客户端B而言就会进入一个while true的死循环,每隔一段时间都尝试去进行加锁,重新执行这段lua脚本

简单画图总结如下:

image.png

客户端C thread03 加锁分析

此时thread03 在10:00:15来加锁,分析一下执行原理:

 1"while true do "
2+ "local firstThreadId2 = redis.call('lindex', KEYS[2], 0);"
3+ "if firstThreadId2 == false then "
4    + "break;"
5+ "end; "
6+ "local timeout = tonumber(redis.call('zscore', KEYS[3], firstThreadId2));"
7+ "if timeout <= tonumber(ARGV[4]) then "
8    + "redis.call('zrem', KEYS[3], firstThreadId2); "
9    + "redis.call('lpop', KEYS[2]); "
10+ "else "
11    + "break;"
12+ "end; "
13+ "end;"

while true死循环,lindex redisson_lock_queue:{anyLock} 0,获取队列中的第一个元素,UUID_02:threadId_02,代表的是这个客户端02正在队列里排队

zscore redisson_lock_timeout:{anyLock} UUID_02:threadId_02,从有序集合中获取UUID_02:threadId_02对应的分数,timeout = 10:00:25

判断:timeout <= 10:00:15?,这个条件不成立,退出死循环

 1"local firstThreadId = redis.call('lindex', KEYS[2], 0); " +
2"local ttl; " + 
3"if firstThreadId ~= false and firstThreadId ~= ARGV[2] then " + 
4    "ttl = tonumber(redis.call('zscore', KEYS[3], firstThreadId)) - tonumber(ARGV[4]);" + 
5"else "
6  + "ttl = redis.call('pttl', KEYS[1]);" + 
7"end; " + 
8
9"local timeout = ttl + tonumber(ARGV[3]);" + 
10"if redis.call('zadd', KEYS[3], timeout, ARGV[2]) == 1 then " +
11    "redis.call('rpush', KEYS[2], ARGV[2]);" +
12"end; " +
13"return ttl;", 

firstThreadId获取到的是队列中的第一个元素:UUID_02:thread_02

ttl = 10:00:25 - 10:00:15 = 5000毫秒
timeout = 5000毫秒 + 10:00:15 + 5000毫秒 = 10:00:30

将客户端C放入到对列和有序集合中:
zadd redisson_lock_timeout:{anyLock} 10:00:30 UUID_03:threadId_03
rpush redisson_lock_queue:{anyLock} UUID_03:theadId_03

最终执行完后 如下图:

image.png

Redisson依次加锁逻辑

上面已经知道了,多个线程加锁过程中实际会进行排队,根据加锁的时间来作为获取锁的优先级,如果此时客户端A释放了锁,来看下客户端B、C是如果获取锁的

当客户端A释放锁
客户端B请求获取锁

直接看核心逻辑:

1+ "if (redis.call('exists', KEYS[1]) == 0) and ((redis.call('exists', KEYS[2]) == 0) "
2+ "or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
3"redis.call('lpop', KEYS[2]); " +
4"redis.call('zrem', KEYS[3], ARGV[2]); " +
5"redis.call('hset', KEYS[1], ARGV[2], 1); " +
6"redis.call('pexpire', KEYS[1], ARGV[1]); " +
7"return nil; " +
8"end; " +

if中的判断:
exists anyLock 是否不存在,此时客户端A已经释放锁,所以这个条件成立。

然后判断队列不存在,或者队列中第一个元素为空,此时条件不成立,但是后面是or关联的判断,接着判断队列中的第一个元素是否为当前请求的UUID_02:threadId_02, 如果判断成功则开始加锁。

这里就是公平锁依次加锁的核心逻辑。

申明

本文章首发自本人博客:https://www.cnblogs.com/wang-meng 和公众号:壹枝花算不算浪漫,如若转载请标明来源!

感兴趣的小伙伴可关注个人公众号:壹枝花算不算浪漫

【分布式锁】02-使用Redisson实现公平锁原理的更多相关文章

  1. Redisson源码解读-公平锁

    前言 我在上一篇文章聊了Redisson的可重入锁,这次继续来聊聊Redisson的公平锁.下面是官方原话: 它保证了当多个Redisson客户端线程同时请求加锁时,优先分配给先发出请求的线程.所有请 ...

  2. Java多线程系列--“JUC锁”03之 公平锁(一)

    概要 本章对“公平锁”的获取锁机制进行介绍(本文的公平锁指的是互斥锁的公平锁),内容包括:基本概念ReentrantLock数据结构参考代码获取公平锁(基于JDK1.7.0_40)一. tryAcqu ...

  3. Java多线程系列--“JUC锁”04之 公平锁(二)

    概要 前面一章,我们学习了“公平锁”获取锁的详细流程:这里,我们再来看看“公平锁”释放锁的过程.内容包括:参考代码释放公平锁(基于JDK1.7.0_40) “公平锁”的获取过程请参考“Java多线程系 ...

  4. Java多线程系列--“JUC锁”05之 非公平锁

    概要 前面两章分析了"公平锁的获取和释放机制",这一章开始对“非公平锁”的获取锁/释放锁的过程进行分析.内容包括:参考代码获取非公平锁(基于JDK1.7.0_40)释放非公平锁(基 ...

  5. JAVA锁机制-可重入锁,可中断锁,公平锁,读写锁,自旋锁,

    如果需要查看具体的synchronized和lock的实现原理,请参考:解决多线程安全问题-无非两个方法synchronized和lock 具体原理(百度) 在并发编程中,经常遇到多个线程访问同一个 ...

  6. 最全Java锁详解:独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁

    在Java并发场景中,会涉及到各种各样的锁如公平锁,乐观锁,悲观锁等等,这篇文章介绍各种锁的分类: 公平锁/非公平锁 可重入锁 独享锁/共享锁 乐观锁/悲观锁 分段锁 自旋锁 01.乐观锁 vs 悲观 ...

  7. Java锁--非公平锁

    转载请注明出处:http://www.cnblogs.com/skywang12345/p/3496651.html 参考代码 下面给出Java1.7.0_40版本中,ReentrantLock和AQ ...

  8. Java锁--公平锁

    转载请注明出处:http://www.cnblogs.com/skywang12345/p/3496147.html 基本概念 本章,我们会讲解“线程获取公平锁”的原理:在讲解之前,需要了解几个基本概 ...

  9. Java并发指南8:AQS中的公平锁与非公平锁,Condtion

    一行一行源码分析清楚 AbstractQueuedSynchronizer (二) 转自https://www.javadoop.com/post/AbstractQueuedSynchronizer ...

随机推荐

  1. 从CVPR 2014看计算机视觉领域的最新热点

    2014看计算机视觉领域的最新热点" title="从CVPR 2014看计算机视觉领域的最新热点"> 编者按:2014年度计算机视觉方向的顶级会议CVPR上月落下 ...

  2. 关于CLOSE BY CLIENT STACK TRACE

    关于CLOSE BY CLIENT STACK TRACE 程序正常运行,数据库连接可以获取,一些列操作都可以实现,可在debug信息中总会一段时间就报如下错误: java.lang.Exceptio ...

  3. Pytorch随机种子

    最近在做比赛的时候,遇到了一个最好结果,但是之后无论怎样都复现不出来最好结果了.猜测是不是跟Pytorch中的随机种子有关. 训练过程 在训练过程中,若相同的数据数据集,相同的训练集.测试集划分方式, ...

  4. jQuery2.0.0版本以后不再支持ie8的原因

    在引用jQuery时,引用高版本的Jq会在IE8下报错,在网上查了一下,jq在2.0+的版本就已经放弃对ie8的支持了.之前没有仔细研究过jq版本,借此机会去看了一下jq版本的知识.一.如何查看jq的 ...

  5. UEditor问题整理

    网上可以使用的富文本编辑器有很多,但是经过慎(sui)重(shou)思(yi)考(cha),选择了UEditor,毕竟是百度的东西,质量上应该经得起推敲,另外,使用别人的插件,总要去适应别人的编码习惯 ...

  6. USB小白学习之路(11) Cy7c68013A驱动电路设计注意事项(转)

    Cy7c68013A驱动电路设计注意事项 转自:http://group.chinaaet.com/116/79029#0-tsina-1-71467-397232819ff9a47a7b7e80a4 ...

  7. Elasticsearch系列---深入全文搜索

    概要 本篇介绍怎样在全文字段中搜索到最相关的文档,包含手动控制搜索的精准度,搜索条件权重控制. 手动控制搜索的精准度 搜索的两个重要维度:相关性(Relevance)和分析(Analysis). 相关 ...

  8. nginx设置目录浏览及中文乱码问题解决

    在Nginx下默认是不允许列出整个目录的.如需此功能, 先打开nginx.conf文件,在location server 或 http段中加入 autoindex on;另外两个参数最好也加上去: a ...

  9. Spring的工作原理

    一.什么是Spring (1).Spring真正的精华是它的Ioc模式实现的BeanFactory和AOP,它自己在这个基础上延伸的功能有些画蛇添足. (2). Spring它是一个开源的项目,而且目 ...

  10. 跟我猜Spring-Boot:bean的创建

    废话在前 最近几年的技术路子很杂,先是node,然后是php,后来是openresty,再后来转到了java,而接触的框架(Framework),也越发的复杂,从最开始的express/koa,到lu ...