- 当前位置：首页 >系统运维 >Redis分布式锁的前世今生
Redis分布式锁的前世今生
发布时间：2025-11-04 07:44:14 来源：创站工坊 作者：系统运维
背景
如今的布式服务大多数是集群化部署，这就使得像synchronized、前世ReentrantLock等传统的今生本地锁失去了功效。因此需要引入第三方的布式服务实现对这些并发进程的调度，从而控制对共享资源的前世访问，像redis、今生zookeeper、布式mysql等。前世其中又以redis的今生应用最为广泛。
分布式锁的布式要素
最重要的两个要素：排他性、容错性。前世
排他性是今生指在分布式应用集群中，同一个方法在同一时间内只能被一台机器上的布式一个线程执行。
容错性是前世指不论正常的业务执行完成，还是今生突发性的程序崩溃或者网络中断，都要保证分布式锁最终一定能得到释放，不能出现死锁现象。
redis分布式锁的基本命令
1、免费源码下载加锁 SETNX key valuesetnx 的含义就是 SET if Not Exists，有两个参数 setnx(key, value)，该方法是原子性操作。如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。
2、解锁 del (key)得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。
3、配置锁超时 expire (key，30s）客户端崩溃或者网络中断，资源将会永远被锁住,即死锁，因此需要给key配置过期时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。
OK，有了上面的理论基础，我们就可以来逐步的揭开redis分布式锁的神秘面纱。
我们以常见的扣减库存的场景为例，当有线程来执行扣减库存的服务器租用方法时，大致逻辑是先判断当前库存，如果还有库存的话，就库存减1，然后生成明细记录。
一把问题很多的锁
首先看一段伪代码。
复制methodA(){
//ID为666的商品库存扣减key String key = "stock:deduct:666" if（setnx（key，1） == 1）{
expire(key,10,TimeUnit.SECONDS)
try{
//查询是否有库存 //扣减库存 //生成明细记录} finally{
del（key）}
}else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法 methodA()
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.这段代码的主要逻辑是，先给ID为666的商品库存上锁，然后设置key的过期时间为10秒，之后就执行扣减库存的逻辑了，等业务逻辑执行完成，就删除key释放锁。在此期间如果有其他线程来获取锁，会上锁失败，失败后就等一会再次调用methodA方法继续尝试上锁，然后循环往复，直到上锁成功。
看上去大功告成了，所谓的分布式锁也不过如此。b2b供应网
然而，正如我们标题上写的，这是一把问题很多的锁，有什么问题呢？
首先最大的问题是，多个命令之间不是原子操作。在setnx和expire之间是分了两步来执行的，如果setnx成功，但是expire却执行失败，或者还没有执行就突发宕机，就造成了这个资源的死锁，违反了我们上面提到的容错性原则。
另外存在的一个问题是，可能会出现线程A删掉了线程B的锁。假设有两个线程A和B，A先上锁成功开始执行业务逻辑，但由于某些原因导致A执行很慢，15秒才执行完，但A的锁有效期只有10秒，A锁过期后，B上锁成功，但是B还没有执行完业务逻辑，线程A业务逻辑执行完成，执行删锁操作，此时删除的，实际上是B的锁，B的锁删掉了，也就无法阻止其他线程来加锁，违反了上面提到的排他性原则。
如何解决这两个问题呢？
优化后的锁
第一个问题，既然多个命令之间不是原子操作，我们用一个命令就行了，而redis恰好也提供了一个这样的命令，setex，即在赋值的时候设置过期时间，这是一个原子命令。对应到java中，也有这样的API供我们使用：
复制redisTemplate.opsForValue().setIfAbsent("key","success",10,TimeUnit.SECONDS)1.第二个问题，可以在删除锁之前做一个判断，验证当前要删除的锁是不是自己的锁，实现方式也很简单，可以将value值设置为当前的线程ID或者随便一个UUID。
优化后的伪代码应该是这样的：
复制methodA(){
//ID为666的商品库存扣减key String key = "stock:deduct:666";
String value = Thread.currentThread().getId();
if（setex（key, 10, value） == 1）{
try{
//查询是否有库存 //扣减库存 //生成明细记录} finally{
if(get(key).equals(value)){
del（key）}
}
}else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法 methodA()
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.这把锁总没问题了吧？
然而，细细考究一下，还是会发现不妥之处。虽然我们删除锁的时候做了判断，但仍有可能删错锁。根本原因是判断锁和删除锁同样不是原子操作。
那到底如何保证绝对的原子性？
lua脚本的横空出世
这里我们不去深究lua脚本是什么，只需要知道，lua是一个脚本语言，redis执行lua脚本的时候，会将它里面的命令当做一个整体去执行，要么全部执行成功，要么出现异常，结果不会更新到redis中。
因此，上面的删锁操作，我们完全可以将判断命令和删除命令都放到lua脚本中，然后由代码去执行lua脚本，最终会实现我们想要的原子操作。
实际上，这也正是redis官方推荐的做法。具体可查看官方文档：set 命令 -- Redis中国用户组（CRUG）。
这里提供一段java中调用lua脚本的代码，大家看了后可以加深理解：
复制String script = "if redis.call(get,KEYS[1]) == ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end";
Integer result = redisTemplate.execute(new DefaultRedisScript<>(script, Integer.class), Arrays.asList(lockKey), uuid);1.2.其中的脚本代码是官方文档中提供的，可以直接复制过来使用。
原生分布式锁
综合上面所说的，一个完整的原生分布式锁应该就是下面这个样子了：
复制methodA(){
//ID为666的商品库存扣减key String key = "stock:deduct:666";
String value = Thread.currentThread().getId();
String script = "if redis.call(get,KEYS[1]) == ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end";
if（setex（key, 10, value） == 1）{
try{
//查询是否有库存 //扣减库存 //生成明细记录} finally{
//解锁 Long result = redisTemplate.execute( new DefaultRedisScript<>(script,Long.class),Arrays.asList(lockKey),uuid);
}
}else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法 methodA()
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.这就是一个比较完善的分布式锁了，既满足了对共享资源的并发控制，又保证了加锁、解锁的原子性操作，防止突发状况造成的死锁问题。
这里大家再想一个问题，如何避免业务执行时间过长锁过期的问题？为了保证排他性，肯定要保证在业务执行时间内，锁是一定不能过期的。在原生的分布式锁中，没有什么好的方法，只能加长锁的过期时间，保证业务一定能执行完成。
那么，有没有更好的解决方案呢？
Hi，我叫redisson
redisson是redis官方推荐的一个分布式锁的框架，它帮我们解决了上面提到的所有问题，底层也是用了lua脚本实现，同时又提供了watchdog(看门狗)机制，在锁将要过期的时候，会自动检测业务是否执行完成，如果没有完成，则自动延长锁的过期时间，直到业务执行完成。而且最重要的一点，使用起来非常简单，几行代码就可以搞定，不像原生锁那样繁琐，是我们进行分布式锁开发的不二选择。这里不做详细描述了，感兴趣的可以在网上搜索一下。
好了，关于redis分布式锁就到这里了。
- Copyright © 2025 Powered by Redis分布式锁的前世今生,创站工坊 滇ICP备2023006006号-44sitemap