作者：微信小助手
发布时间：2021-09-30T12:01:24
在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首先，被我们用到了很多实际业务场景当中。 但不是说用了redis分布式锁，就可以高枕无忧了，如果没有用好或者用对，也会引来一些意想不到的问题。 今天我们就一起聊聊redis分布式锁的一些坑，给有需要的朋友一个参考。 使用redis的分布式锁，我们首先想到的可能是 容易，三下五除二，我们就可以把代码写好。 这段代码确实可以加锁成功，但你有没有发现什么问题？ 假如加锁成功，但是设置超时时间失败了，该lockKey就变成永不失效。假如在高并发场景中，有大量的lockKey加锁成功了，但不会失效，有可能直接导致redis内存空间不足。 那么，有没有保证原子性的加锁命令呢？ 答案是：有，请看下面。 上面说到使用 而在redis中还有 其中： nice 使用 分布式锁更合理的用法是： 大致流程图如下： 伪代码如下： 需要捕获业务代码的异常，然后在 此时，有些朋友可能会问：假如刚好在释放锁的时候，系统被重启了，或者网络断线了，或者机房断点了，不也会导致释放锁失败？ 这是一个好问题，因为这种小概率问题确实存在。 但还记得前面我们给锁设置过超时时间吗？即使出现异常情况造成释放锁失败，但到了我们设定的超时时间，锁还是会被redis自动释放。 但只在finally中释放锁，就够了吗？ 做人要厚道，先回答上面的问题：只在finally中释放锁，当然是不够的，因为释放锁的姿势，还是不对。 哪里不对？ 答：在多线程场景中，可能会出现释放了别人的锁的情况。 有些朋友可能会反驳：假设在多线程场景中，线程A获取到了锁，但如果线程A没有释放锁，此时，线程B是获取不到锁的，何来释放了别人锁之说？ 答：假如线程A和线程B，都使用lockKey加锁。线程A加锁成功了，但是由于业务功能耗时时间很长，超过了设置的超时时间。这时候，redis会自动释放lockKey锁。此时，线程B就能给lockKey加锁成功了，接下来执行它的业务操作。恰好这个时候，线程A执行完了业务功能，接下来，在finally方法中释放了锁lockKey。这不就出问题了，线程B的锁，被线程A释放了。 我想这个时候，线程B肯定哭晕在厕所里，并且嘴里还振振有词。 那么，如何解决这个问题呢？ 不知道你们注意到没？在使用 答：requestId是在释放锁的时候用的。 伪代码如下： 在释放锁的时候，先获取到该锁的值（之前设置值就是requestId），然后判断跟之前设置的值是否相同，如果相同才允许删除锁，返回成功。如果不同，则直接返回失败。 换句话说就是：自己只能释放自己加的锁，不允许释放别人加的锁。 这里为什么要用requestId，用userId不行吗？ 答：如果用userId的话，对于请求来说并不唯一，多个不同的请求，可能使用同一个userId。而requestId是全局唯一的，不存在加锁和释放锁乱掉的情况。 此外，使用lua脚本，也能解决释放了别人的锁的问题： lua脚本能保证查询锁是否存在和删除锁是原子操作，用它来释放锁效果更好一些。 说到lua脚本，其实加锁操作也建议使用lua脚本： 这是redisson框架的加锁代码，写的不错，大家可以借鉴一下。 有趣，下面还有哪些好玩的东西？ 上面的加锁方法看起来好像没有问题，但如果你仔细想想，如果有1万的请求同时去竞争那把锁，可能只有一个请求是成功的，其余的9999个请求都会失败。 在秒杀场景下，会有什么问题？ 答：每1万个请求，有1个成功。再1万个请求，有1个成功。如此下去，直到库存不足。这就变成均匀分布的秒杀了，跟我们想象中的不一样。 如何解决这个问题呢？ 此外，还有一种场景： 比如，有两个线程同时上传文件到sftp，上传文件前先要创建目录。假设两个线程需要创建的目录名都是当天的日期，比如：20210920，如果不做任何控制，直接并发的创建目录，第二个线程必然会失败。 这时候有些朋友可能会说：这还不容易，加一个redis分布式锁就能解决问题了，此外再判断一下，如果目录已经存在就不创建，只有目录不存在才需要创建。 伪代码如下：前言
1 非原子操作
setNx命令。if (jedis.setnx(lockKey, val) == 1) {
jedis.expire(lockKey, timeout);
}加锁操作和后面的设置超时时间是分开的，并非原子操作。2 忘了释放锁
setNx命令加锁操作和设置超时时间是分开的，并非原子操作。set命令，该命令可以指定多个参数。String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
lockKey：锁的标识
requestId：请求id
NX：只在键不存在时，才对键进行设置操作。
PX：设置键的过期时间为 millisecond 毫秒。
expireTime：过期时间
set命令是原子操作，加锁和设置超时时间，一个命令就能轻松搞定。set命令加锁，表面上看起来没有问题。但如果仔细想想，加锁之后，每次都要达到了超时时间才释放锁，会不会有点不合理？加锁后，如果不及时释放锁，会有很多问题。
那么问题来了，如何释放锁呢？try{
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
} finally {
unlock(lockKey);
} finally中释放锁。换句话说就是：无论代码执行成功或失败了，都需要释放锁。3 释放了别人的锁
set命令加锁时，除了使用lockKey锁标识，还多设置了一个参数：requestId，为什么要需要记录requestId呢？if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false;
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
endif (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
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1)
redis.call('hincrby', KEYS[1], ARGV[2], 1);
redis.call('pexpire', KEYS[1], ARGV[1]);
return nil;
end;
return redis.call('pttl', KEYS[1]);4 大量失败请求