Redis分布式锁

2024-07-16 02:56| 来源: 网络整理| 查看: 265

前言

在某些场景中，多个进程必须以互斥的方式独占共享资源，这时用分布式锁是最直接有效的。

随着技术快速发展，数据规模增大，分布式系统越来越普及，一个应用往往会部署在多台机器上（多节点），在有些场景中，为了保证数据不重复，要求在同一时刻，同一任务只在一个节点上运行，即保证某一方法同一时刻只能被一个线程执行。在单机环境中，应用是在同一进程下的，只需要保证单进程多线程环境中的线程安全性，通过 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent 并发包下一些线程安全的类等就可以做到。而在多机部署环境中，不同机器不同进程，就需要在多进程下保证线程的安全性了。因此，分布式锁应运而生。

以往的工作中看到或用到几种实现方案，有基于zk的，也有基于redis的。由于实现上逻辑不严谨，线上时不时会爆出几个死锁case。那么，究竟什么样的分布式锁实现，才算是比较好的方案？

常见分布式锁方案对比分类方案实现原理优点缺点基于数据库基于mysql 表唯一索引1.表增加唯一索引 2.加锁：执行insert语句，若报错，则表明加锁失败 3.解锁：执行delete语句完全利用DB现有能力，实现简单1.锁无超时自动失效机制，有死锁风险 2.不支持锁重入，不支持阻塞等待 3.操作数据库开销大，性能不高基于MongoDB findAndModify原子操作1.加锁：执行findAndModify原子命令查找document，若不存在则新增 2.解锁：删除document实现也很容易，较基于MySQL唯一索引的方案，性能要好很多1.大部分公司数据库用MySQL，可能缺乏相应的MongoDB运维、开发人员 2.锁无超时自动失效机制基于分布式协调系统基于ZooKeeper1.加锁：在/lock目录下创建临时有序节点，判断创建的节点序号是否最小。若是，则表示获取到锁；否，则则watch /lock目录下序号比自身小的前一个节点 2.解锁：删除节点1.由zk保障系统高可用 2.Curator框架已原生支持系列分布式锁命令，使用简单需单独维护一套zk集群，维保成本高基于缓存基于redis命令1. 加锁：执行setnx，若成功再执行expire添加过期时间 2. 解锁：执行delete命令实现简单，相比数据库和分布式系统的实现，该方案最轻，性能最好1.setnx和expire分2步执行，非原子操作；若setnx执行成功，但expire执行失败，就可能出现死锁 2.delete命令存在误删除非当前线程持有的锁的可能 3.不支持阻塞等待、不可重入基于redis Lua脚本能力1. 加锁：执行SET lock_name random_value EX seconds NX 命令 2. 解锁：执行Lua脚本，释放锁时验证random_value -- ARGV[1]为random_value, KEYS[1]为lock_name

if redis.call("get", KEYS[1]) == ARGV[1] then

return redis.call("del",KEYS[1])

else

return 0

end

同上；实现逻辑上也更严谨，除了单点问题，生产环境采用用这种方案，问题也不大。不支持锁重入，不支持阻塞等待

表格中对比了几种常见的方案，redis+lua基本可应付工作中分布式锁的需求。然而，当偶然看到redisson分布式锁实现方案(传送门)，相比以上方案，redisson保持了简单易用、支持锁重入、支持阻塞等待、Lua脚本原子操作，不禁佩服作者精巧的构思和高超的编码能力。下面就来学习下redisson这个牛逼框架，是怎么实现的。

分布式锁需满足四个条件

首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

互斥性。在任意时刻，只有一个客户端能持有锁。不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了，即不能误解锁。具有容错性。只要大多数Redis节点正常运行，客户端就能够获取和释放锁。 Redisson分布式锁的实现

Redisson 分布式重入锁用法

Redisson 支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例：

// 1.构造redisson实现分布式锁必要的Config Config config = new Config(); config.useSingleServer().setAddress("redis://127.0.0.1:5379").setPassword("123456").setDatabase(0); // 2.构造RedissonClient RedissonClient redissonClient = Redisson.create(config); // 3.获取锁对象实例（无法保证是按线程的顺序获取到） RLock rLock = redissonClient.getLock(lockKey); try { /** * 4.尝试获取锁 * waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败 * leaseTime 锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完） */ boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS); if (res) { //成功获得锁，在这里处理业务 } } catch (Exception e) { throw new RuntimeException("aquire lock fail"); }finally{ //无论如何, 最后都要解锁 rLock.unlock(); }

redisson这个框架重度依赖了Lua脚本和Netty，代码很牛逼，各种Future及FutureListener的异步、同步操作转换。

自己先思考下,如果要手写一个分布式锁组件，怎么做？肯定要定义2个接口：加锁、解锁；大道至简，redisson的作者就是在加锁和解锁的执行层面采用Lua脚本，逼格高，而且重要有原子性保证啊。当然，redisson的作者毕竟牛逼，加锁和解锁过程中还巧妙地利用了redis的发布订阅功能，后面会讲到。下面先对加锁和解锁Lua脚本了解下。

加锁&解锁Lua脚本

加锁、解锁Lua脚本是redisson分布式锁实现最重要的组成部分。首先不看代码，先研究下Lua脚本都是什么逻辑

1、加锁Lua脚本脚本入参参数示例值含义KEY个数1KEY个数KEYS[1]my_first_lock_name锁名ARGV[1]60000持有锁的有效时间：毫秒ARGV[2]58c62432-bb74-4d14-8a00-9908cc8b828f:1唯一标识：获取锁时set的唯一值，实现上为redisson客户端ID(UUID)+线程ID 脚本内容 -- 若锁不存在：则新增锁，并设置锁重入计数为1、设置锁过期时间 if (redis.call('exists', KEYS[1]) == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; -- 若锁存在，且唯一标识也匹配：则表明当前加锁请求为锁重入请求，故锁重入计数+1，并再次设置锁过期时间 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]); 脚本解读

Q：返回nil、返回剩余过期时间有什么目的？ A：当且仅当返回nil，才表示加锁成功；客户端需要感知加锁是否成功的结果

2、解锁Lua脚本脚本入参参数示例值含义KEY个数2KEY个数KEYS[1]my_first_lock_name锁名KEYS[2]redisson_lock__channel:{my_first_lock_name}解锁消息PubSub频道ARGV[1]0redisson定义0表示解锁消息ARGV[2]30000设置锁的过期时间；默认值30秒ARGV[3]58c62432-bb74-4d14-8a00-9908cc8b828f:1唯一标识；同加锁流程脚本内容 -- 若锁不存在：则直接广播解锁消息，并返回1 if (redis.call('exists', KEYS[1]) == 0) then redis.call('publish', KEYS[2], ARGV[1]); return 1; end; -- 若锁存在，但唯一标识不匹配：则表明锁被其他线程占用，当前线程不允许解锁其他线程持有的锁 if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then return nil; end; -- 若锁存在，且唯一标识匹配：则先将锁重入计数减1 local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); if (counter > 0) then -- 锁重入计数减1后还大于0：表明当前线程持有的锁还有重入，不能进行锁删除操作，但可以友好地帮忙设置下过期时期 redis.call('pexpire', KEYS[1], ARGV[2]); return 0; else -- 锁重入计数已为0：间接表明锁已释放了。直接删除掉锁，并广播解锁消息，去唤醒那些争抢过锁但还处于阻塞中的线程 redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end; return nil;

脚本解读

Q1：广播解锁消息有什么用？ A：是为了通知其他争抢锁阻塞住的线程，从阻塞中解除，并再次去争抢锁。

Q2：返回值0、1、nil有什么不一样？ A：当且仅当返回1，才表示当前请求真正触发了解锁Lua脚本；但客户端又并不关心解锁请求的返回值，好像没什么用？

源码搞起

1、加锁流程源码

读加锁源码时，可以把tryAcquire(leaseTime, unit, threadId)方法直接视为执行加锁Lua脚本。直接进入org.redisson.RedissonLock#tryLock(long, long, java.util.concurrent.TimeUnit)源码

@Override public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException { // 获取锁能容忍的最大等待时长 long time = unit.toMillis(waitTime); long current = System.currentTimeMillis(); final long threadId = Thread.currentThread().getId(); // 【核心点1】尝试获取锁，若返回值为null，则表示已获取到锁 Long ttl = tryAcquire(leaseTime, unit, threadId); // lock acquired if (ttl == null) { return true; } // 还可以容忍的等待时长=获取锁能容忍的最大等待时长 - 执行完上述操作流逝的时间 time -= (System.currentTimeMillis() - current); if (time

【本文地址】

公司简介

联系我们