专业的单位网站开发开发,社区做图网站有哪些,phpmysql网站,快3网站制作 优帮云ReentrantLock 重入锁在说 Redisson 之前我们先来说一下 JDK 可重入锁: ReentrantLockReentrantLock 保证了 JVM 共享资源同一时刻只允许单个线程进行操作实现思路ReentrantLock 内部公平锁与非公平锁继承了 AQS[AbstractQueuedSynchronizer]1、AQS 内部通过 volatil 修饰的 in… ReentrantLock 重入锁在说 Redisson 之前我们先来说一下 JDK 可重入锁: ReentrantLockReentrantLock 保证了 JVM 共享资源同一时刻只允许单个线程进行操作实现思路ReentrantLock 内部公平锁与非公平锁继承了 AQS[AbstractQueuedSynchronizer]1、AQS 内部通过 volatil 修饰的 int 类型变量 state 控制并发情况下线程安全问题及锁重入2、将未竞争到锁的线程放入 AQS 的队列中通过 LockSupport#park、unPark 挂起唤醒简要描述哈, 详情可以查看具体的文章Redisson可以直接查看 Github Redisson官网 介绍, 没有了解过的小伙伴, 看一下 Redisson 的 WIKI 目录, 仔细瞅瞅 Redis 是如何被 Redisson 武装到牙齿的 上下滚动查看更多这里先过一下和文章有关的一部分内容通过项目简介可以看出来, 写这个项目介绍的人水平非常哇塞哈, 从第一段咱们就知道了两个问题Redisson 是什么Redisson 是架设在 Redis 基础上的一个 Java 驻内存数据网格框架, 充分利用 Redis 键值数据库提供的一系列优势, 基于 Java 实用工具包中常用接口, 为使用者提供了 一系列具有分布式特性的常用工具类Redisson 的优势使得原本作为协调单机多线程并发程序的工具包 获得了协调分布式多机多线程并发系统的能力, 大大降低了设计和研发大规模分布式系统的难度同时结合各富特色的分布式服务, 更进一步 简化了分布式环境中程序相互之间的协作“了解到这里就差不多了, 就不向下扩展了, 想要了解详细用途的, 翻一下上面的目录Redisson 重入锁由于 Redisson 太过于复杂, 设计的 API 调用大多用 Netty 相关, 所以这里只对 如何加锁、如何实现重入锁进行分析以及如何锁续时进行分析创建锁我这里是将 Redisson 的源码下载到本地了下面这个简单的程序, 就是使用 Redisson 创建了一个非公平的可重入锁lock() 方法加锁成功 默认过期时间 30 秒, 并且支持 看门狗 续时功能public static void main(String[] args) {Config config new Config();config.useSingleServer().setPassword(123456).setAddress(redis://127.0.0.1:6379);RedissonClient redisson Redisson.create(config);RLock lock redisson.getLock(myLock);try {lock.lock();// 业务逻辑} finally {lock.unlock();}
}
我们先来看一下 RLock 接口的声明public interface RLock extends Lock, RLockAsync {}
RLock 继承了 JDK 源码 JUC 包下的 Lock 接口, 同时也继承了 RLockAsyncRLockAsync 从字面意思看是 支持异步的锁, 证明获取锁时可以异步获取“看了 Redisson 的源码会知道, 注释比黄金贵 ????️由于获取锁的 API 较多, 我们这里以 lock() 做源码讲解, 看接口定义相当简单/*** lock 并没有指定锁过期时间, 默认 30 秒* 如果获取到锁, 会对锁进行续时*/
void lock();
获取锁实例根据上面的小 Demo, 看下第一步获取锁是如何做的RLock lock redisson.getLock(myLock);// name 就是锁名称
public RLock getLock(String name) {// 默认创建的同步执行器, (存在异步执行器, 因为锁的获取和释放是有强一致性要求, 默认同步)return new RedissonLock(connectionManager.getCommandExecutor(), name);
}
Redisson 中所有 Redis 命令都是通过 ...Executor 执行的获取到默认的同步执行器后, 就要初始化 RedissonLockpublic RedissonLock(CommandAsyncExecutor commandExecutor, String name) {super(commandExecutor, name);this.commandExecutor commandExecutor;// 唯一IDthis.id commandExecutor.getConnectionManager().getId();// 等待获取锁时间this.internalLockLeaseTime commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout();// ID 锁名称this.entryName id : name;// 发布订阅, 后面关于加、解锁流程会用到this.pubSub commandExecutor.getConnectionManager().getSubscribeService().getLockPubSub();
}
尝试获取锁我们来看一下 RLock#lock() 底层是如何获取锁的Override
public void lock() {try {lock(-1, null, false);} catch (InterruptedException e) {throw new IllegalStateException();}
}
leaseTime: 加锁到期时间, -1 使用默认值 30 秒unit: 时间单位, 毫秒、秒、分钟、小时...interruptibly: 是否可被中断标示private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {// 获取当前线程IDlong threadId Thread.currentThread().getId();// ???? 尝试获取锁, 下面重点分析Long ttl tryAcquire(-1, leaseTime, unit, threadId);// 成功获取锁, 过期时间为空if (ttl null) {return;}// 订阅分布式锁, 解锁时进行通知RFutureRedissonLockEntry future subscribe(threadId);if (interruptibly) {commandExecutor.syncSubscriptionInterrupted(future);} else {commandExecutor.syncSubscription(future);}try {while (true) {// 再次尝试获取锁ttl tryAcquire(-1, leaseTime, unit, threadId);// 成功获取锁, 过期时间为空, 成功返回if (ttl null) {break;}// 锁过期时间如果大于零, 则进行带过期时间的阻塞获取if (ttl 0) {try {// 获取不到锁会在这里进行阻塞, Semaphore, 解锁时释放信号量通知future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);} catch (InterruptedException e) {if (interruptibly) {throw e;}future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);}// 锁过期时间小于零, 则死等, 区分可中断及不可中断} else {if (interruptibly) {future.getNow().getLatch().acquire();} else {future.getNow().getLatch().acquireUninterruptibly();}}}} finally {// 取消订阅unsubscribe(future, threadId);}
}
这一段代码是用来执行加锁, 继续看下方法实现Long ttl tryAcquire(-1, leaseTime, unit, threadId);private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {return get(tryAcquireAsync(waitTime, leaseTime, unit, threadId));
}
lock() 以及 tryLock(...) 方法最终都会调用此方法, 分为两个流程分支1、tryLock(...) API 异步加锁返回2、lock() tryLock() API 异步加锁并进行锁续时private T RFutureLong tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {// 执行 tryLock(...) 才会进入if (leaseTime ! -1) {// 进行异步获取锁return tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);}// 尝试异步获取锁, 获取锁成功返回空, 否则返回锁剩余过期时间RFutureLong ttlRemainingFuture tryLockInnerAsync(waitTime,commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);// ttlRemainingFuture 执行完成后触发此操作ttlRemainingFuture.onComplete((ttlRemaining, e) - {if (e ! null) {return;}// ttlRemaining null 代表获取了锁// 获取到锁后执行续时操作if (ttlRemaining null) {scheduleExpirationRenewal(threadId);}});return ttlRemainingFuture;
}
继续看一下 tryLockInnerAsync(...) 详细的加锁流程, 内部采用的 Lua 脚本形式, 保证了原子性操作到这一步大家就很明了了, 将 Lua 脚本被 Redisoon 包装最后通过 Netty 进行传输T RFutureT tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommandT command) {internalLockLeaseTime unit.toMillis(leaseTime);return evalWriteAsync(getName(), LongCodec.INSTANCE, command,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]);,Collections.singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
}
“evalWriteAsync(...) 是对 Eval 命令的封装以及 Netty 的应用就不继续跟进了加锁 Lua执行 Redis 加锁的 Lua 脚本, 截个图让大家看一下参数以及具体含义KEYS[1]: myLockARGV[1]: 36000... 这个是过期时间, 自己测试的, 单位毫秒ARGV[2]: UUID 线程 ID# KEYS[1] 代表上面的 myLock
# 判断 KEYS[1] 是否存在, 存在返回 1, 不存在返回 0
if (redis.call(exists, KEYS[1]) 0) then# 当 KEYS[1] 0 时代表当前没有锁# 使用 hincrby 命令发现 KEYS[1] 不存在并新建一个 hash# ARGV[2] 就作为 hash 的第一个key, val 为 1# 相当于执行了 hincrby myLock 91089b45... 1redis.call(hincrby, KEYS[1], ARGV[2], 1);# 设置 KEYS[1] 过期时间, 单位毫秒redis.call(pexpire, KEYS[1], ARGV[1]);return nil;
end;
# 查找 KEYS[1] 中 key ARGV[2] 是否存在, 存在回返回 1
if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then# 同上, ARGV[2] 为 key 的 val 1redis.call(hincrby, KEYS[1], ARGV[2], 1);# 同上redis.call(pexpire, KEYS[1], ARGV[1]);
return nil;
end;
# 返回 KEYS[1] 过期时间, 单位毫秒
return redis.call(pttl, KEYS[1]);
整个 Lua 脚本加锁的流程画图如下:现在回过头看一下获取到锁之后, 是如何为锁进行延期操作的锁续时之前有和军哥聊过这个话题, 他说的思路和 Redisson 中体现的基本一致说一下 Redisson 的具体实现思路吧, 中文翻译叫做 看门狗1、获取到锁之后执行 看门狗 流程2、使用 Netty 的 Timeout 实现定时延时3、比如锁过期 30 秒, 每过 1/3 时间也就是 10 秒会检查锁是否存在, 存在则更新锁的超时时间可能会有小伙伴会提出这么一个疑问, 如果检查返回存在, 设置锁过期时刚好锁被释放了怎么办?有这样的疑问, 代表确实用心去考虑所有可能发生的情况了, 但是不必担心哈Redisson 中使用的 Lua 脚本做的检查及设置过期时间操作, 本身是原子性的不会出现上面情况“如果不想要引用 Netty 的包, 使用延时队列等包工具也是可以完成 看门狗这里也贴一哈相关代码, 能够让小伙伴更直观的了解如何锁续时的我可真是个暖男, 上代码 RedissonLock#tryAcquireAsync(...)private T RFutureLong tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {// ...// 尝试异步获取锁, 获取锁成功返回空, 否则返回锁剩余过期时间RFutureLong ttlRemainingFuture tryLockInnerAsync(waitTime,commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);// ttlRemainingFuture 执行完成后触发此操作ttlRemainingFuture.onComplete((ttlRemaining, e) - {if (e ! null) {return;}// 获取到锁后执行续时操作if (ttlRemaining null) {scheduleExpirationRenewal(threadId);}});return ttlRemainingFuture;
}
可以看到续时方法将 threadId 当作标识符进行续时private void scheduleExpirationRenewal(long threadId) {ExpirationEntry entry new ExpirationEntry();ExpirationEntry oldEntry EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);if (oldEntry ! null) {oldEntry.addThreadId(threadId);} else {entry.addThreadId(threadId);renewExpiration();}
}
知道核心理念就好了, 没必要研究每一行代码哈private void renewExpiration() {ExpirationEntry ee EXPIRATION_RENEWAL_MAP.get(getEntryName());if (ee null) {return;}Timeout task commandExecutor.getConnectionManager().newTimeout(new TimerTask() {Overridepublic void run(Timeout timeout) throws Exception {ExpirationEntry ent EXPIRATION_RENEWAL_MAP.get(getEntryName());if (ent null) {return;}Long threadId ent.getFirstThreadId();if (threadId null) {return;}RFutureBoolean future renewExpirationAsync(threadId);future.onComplete((res, e) - {if (e ! null) {log.error(Cant update lock getName() expiration, e);return;}if (res) {// 调用本身renewExpiration();}});}}, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);ee.setTimeout(task);
}
解锁操作解锁时的操作相对加锁还是比较简单的Override
public void unlock() {try {get(unlockAsync(Thread.currentThread().getId()));} catch (RedisException e) {if (e.getCause() instanceof IllegalMonitorStateException) {throw (IllegalMonitorStateException) e.getCause();} else {throw e;}}
}
解锁成功后会将之前的看门狗 Timeout 续时取消, 并返回成功Override
public RFutureVoid unlockAsync(long threadId) {RPromiseVoid result new RedissonPromiseVoid();RFutureBoolean future unlockInnerAsync(threadId);future.onComplete((opStatus, e) - {// 取消自动续时功能cancelExpirationRenewal(threadId);if (e ! null) {// 失败result.tryFailure(e);return;}if (opStatus null) {IllegalMonitorStateException cause new IllegalMonitorStateException(attempt to unlock lock, not locked by current thread by node id: id thread-id: threadId);result.tryFailure(cause);return;}// 解锁成功result.trySuccess(null);});return result;
}
又是一个精髓点, 解锁的 Lua 脚本定义protected RFutureBoolean unlockInnerAsync(long threadId) {return evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,if (redis.call(hexists, KEYS[1], ARGV[3]) 0) then return nil; end; local counter redis.call(hincrby, KEYS[1], ARGV[3], -1); if (counter 0) then redis.call(pexpire, KEYS[1], ARGV[2]); return 0; else redis.call(del, KEYS[1]); redis.call(publish, KEYS[2], ARGV[1]); return 1; end; return nil;,Arrays.asList(getName(), getChannelName()), LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId));
}
还是来张图理解哈, Lua 脚本会详细分析解锁 Lua老规矩, 图片加参数说明KEYS[1]: myLockKEYS[2]: redisson_lock_channel:{myLock}ARGV[1]: 0ARGV[2]: 360000... (过期时间)ARGV[3]: 7f0c54e2...(Hash 中的锁 Key)# 判断 KEYS[1] 中是否存在 ARGV[3]
if (redis.call(hexists, KEYS[1], ARGV[3]) 0) then
return nil;
end;
# 将 KEYS[1] 中 ARGV[3] Val - 1
local counter redis.call(hincrby, KEYS[1], ARGV[3], -1);
# 如果返回大于0 证明是一把重入锁
if (counter 0) then# 重制过期时间redis.call(pexpire, KEYS[1], ARGV[2]);
return 0;
else# 删除 KEYS[1]redis.call(del, KEYS[1]);# 通知阻塞等待线程或进程资源可用redis.call(publish, KEYS[2], ARGV[1]);
return 1;
end;
return nil;
Redlock 算法不可否认, Redisson 设计的分布式锁真的很 NB, 但是还是没有解决 主从节点下异步同步数据导致锁丢失问题所以 Redis 作者 Antirez 推出 红锁算法, 这个算法的精髓就是: 没有从节点, 如果部署多台 Redis, 各实例之间相互独立, 不存在主从复制或者其他集群协调机制如何使用创建多个 Redisson Node, 由这些无关联的 Node 组成一个完整的分布式锁public static void main(String[] args) {String lockKey myLock;Config config new Config();config.useSingleServer().setPassword(123456).setAddress(redis://127.0.0.1:6379);Config config2 new Config();config.useSingleServer().setPassword(123456).setAddress(redis://127.0.0.1:6380);Config config3 new Config();config.useSingleServer().setPassword(123456).setAddress(redis://127.0.0.1:6381);RLock lock Redisson.create(config).getLock(lockKey);RLock lock2 Redisson.create(config2).getLock(lockKey);RLock lock3 Redisson.create(config3).getLock(lockKey);RedissonRedLock redLock new RedissonRedLock(lock, lock2, lock3);try {redLock.lock();} finally {redLock.unlock();}
}
当然, 对于 Redlock 算法不是没有质疑声, 大家可以去 Redis 官网查看Martin Kleppmann 与 Redis 作者Antirez 的辩论CAP 原则之间的取舍CAP 原则又称 CAP 定理, 指的是在一个分布式系统中, Consistency一致性、 Availability可用性、Partition tolerance分区容错性, 三者不可得兼一致性(C) : 在分布式系统中的所有数据备份, 在同一时刻是否同样的值(等同于所有节点访问同一份最新的数据副本)可用性(A): 在集群中一部分节点故障后, 集群整体是否还能响应客户端的读写请求(对数据更新具备高可用性)分区容忍性(P): 以实际效果而言, 分区相当于对通信的时限要求. 系统如果不能在时限内达成数据一致性, 就意味着发生了分区的情况, 必须就当前操作在 C 和 A 之间做出选择分布式锁选型如果要满足上述分布式锁之间的强一致性, 可以采用 Zookeeper 的分布式锁, 因为它底层的 ZAB协议(原子广播协议), 天然满足 CP但是这也意味着性能的下降, 所以不站在具体数据下看 Redis 和 Zookeeper, 代表着性能和一致性的取舍如果项目没有强依赖 ZK, 使用 Redis 就好了, 因为现在 Redis 用途很广, 大部分项目中都引用了 Redis没必要对此再引入一个新的组件, 如果业务场景对于 Redis 异步方式的同步数据造成锁丢失无法忍受, 在业务层处理就好了
往期推荐
Redis为什么变慢了一文详解Redis性能问题 | 万字长文Redis 消息队列的三种方案List、Streams、Pub/Sub硬核Redis总结看这篇就够了
