程序地带

面试官:你真的了解Redis分布式锁吗?



什么是分布式锁

说到Redis,我们第一想到的功能就是可以缓存数据,除此之外,Redis因为单进程、性能高的特点,它还经常被用于做分布式锁。


锁我们都知道,在程序中的作用就是同步工具,保证共享资源在同一时刻只能被一个线程访问,Java中的锁我们都很熟悉了,像synchronized 、Lock都是我们经常使用的,但是Java的锁只能保证单机的时候有效,分布式集群环境就无能为力了,这个时候我们就需要用到分布式锁。


分布式锁,顾名思义,就是分布式项目开发中用到的锁,可以用来控制分布式系统之间同步访问共享资源,一般来说,分布式锁需要满足的特性有这么几点:


1、互斥性:在任何时刻,对于同一条数据,只有一台应用可以获取到分布式锁;


2、高可用性:在分布式场景下,一小部分服务器宕机不影响正常使用,这种情况就需要将提供分布式锁的服务以集群的方式部署;


3、防止锁超时:如果客户端没有主动释放锁,服务器会在一段时间之后自动释放锁,防止客户端宕机或者网络不可达时产生死锁;


4、独占性:加锁解锁必须由同一台服务器进行,也就是锁的持有者才可以释放锁,不能出现你加的锁,别人给你解锁了;


业界里可以实现分布式锁效果的工具很多,但操作无非这么几个:加锁、解锁、防止锁超时。


既然本文说的是Redis分布式锁,那我们理所当然就以Redis的知识点来延伸。


实现锁的命令

先介绍下Redis的几个命令,


1、SETNX,用法是SETNX key value


SETNX是『 SET if Not eXists』(如果不存在,则 SET)的简写,设置成功就返回1,否则返回0。



可以看出,当把key为lock的值设置为"Java"后,再设置成别的值就会失败,看上去很简单,也好像独占了锁,但有个致命的问题,就是key没有过期时间,这样一来,除非手动删除key或者获取锁后设置过期时间,不然其他线程永远拿不到锁。


既然这样,我们给key加个过期时间总可以吧,直接让线程获取锁的时候执行两步操作:


SETNX Key 1
EXPIRE Key Seconds

这个方案也有问题,因为获取锁和设置过期时间分成两步了,不是原子性操作,有可能获取锁成功但设置时间失败,那样不就白干了吗。


不过也不用急,这种事情Redis官方早为我们考虑到了,所以就引出了下面这个命令


2、SETEX,用法SETEX key seconds value


将值 value 关联到 key ,并将 key 的生存时间设为 seconds (以秒为单位)。如果 key 已经存在,SETEX 命令将覆写旧值。


这个命令类似于以下两个命令:


SET key value
EXPIRE key seconds # 设置生存时间

这两步动作是原子性的,会在同一时间完成。



3、PSETEX ,用法PSETEX key milliseconds value


这个命令和SETEX命令相似,但它以毫秒为单位设置 key 的生存时间,而不是像SETEX命令那样,以秒为单位。


不过,从Redis 2.6.12 版本开始,SET命令可以通过参数来实现和SETNX、SETEX、PSETEX 三个命令的效果。


就比如这条命令


SET key value NX EX seconds

加上NX、EX参数后,效果就相当于SETEX,这也是Redis获取锁写法里面最常见的。


怎么释放锁

释放锁的命令就简单了,直接删除key就行,但我们前面说了,因为分布式锁必须由锁的持有者自己释放,所以我们必须先确保当前释放锁的线程是持有者,没问题了再删除,这样一来,就变成两个步骤了,似乎又违背了原子性了,怎么办呢?


不慌,我们可以用lua脚本把两步操作做拼装,就好像这样:


if redis.call("get",KEYS[1]) == ARGV[1]
then
return redis.call("del",KEYS[1])
else
return 0
end

KEYS[1]是当前key的名称,ARGV[1]可以是当前线程的ID(或者其他不固定的值,能识别所属线程即可),这样就可以防止持有过期锁的线程,或者其他线程误删现有锁的情况出现。


代码实现

知道了原理后,我们就可以手写代码来实现Redis分布式锁的功能了,因为本文的目的主要是为了讲解原理,不是为了教大家怎么写分布式锁,所以我就用伪代码实现了。


首先是redis锁的工具类,包含了加锁和解锁的基础方法:


public class RedisLockUtil {
private String LOCK_KEY = "redis_lock";
// key的持有时间,5ms
private long EXPIRE_TIME = 5;
// 等待超时时间,1s
private long TIME_OUT = 1000;
// redis命令参数,相当于nx和px的命令合集
private SetParams params = SetParams.setParams().nx().px(EXPIRE_TIME);
// redis连接池,连的是本地的redis客户端
JedisPool jedisPool = new JedisPool("127.0.0.1", 6379);
/**
* 加锁
*
* @param id
* 线程的id,或者其他可识别当前线程且不重复的字段
* @return
*/
public boolean lock(String id) {
Long start = System.currentTimeMillis();
Jedis jedis = jedisPool.getResource();
try {
for (;;) {
// SET命令返回OK ,则证明获取锁成功
String lock = jedis.set(LOCK_KEY, id, params);
if ("OK".equals(lock)) {
return true;
}
// 否则循环等待,在TIME_OUT时间内仍未获取到锁,则获取失败
long l = System.currentTimeMillis() - start;
if (l >= TIME_OUT) {
return false;
}
try {
// 休眠一会,不然反复执行循环会一直失败
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally {
jedis.close();
}
}
/**
* 解锁
*
* @param id
* 线程的id,或者其他可识别当前线程且不重复的字段
* @return
*/
public boolean unlock(String id) {
Jedis jedis = jedisPool.getResource();
// 删除key的lua脚本
String script = "if redis.call("get",KEYS[1]) == ARGV[1] then" + " return redis.call("del",KEYS[1]) " + "else"
+ " return 0 " + "end";
try {
String result =
jedis.eval(script, Collections.singletonList(LOCK_KEY), Collections.singletonList(id)).toString();
return "1".equals(result);
} finally {
jedis.close();
}
}
}

具体的代码作用注释已经写得很清楚了,然后我们就可以写一个demo类来测试一下效果:


public class RedisLockTest {
private static RedisLockUtil demo = new RedisLockUtil();
private static Integer NUM = 101;
public static void main(String[] args) {
for (int i = 0; i < 100; i++) {
new Thread(() -> {
String id = Thread.currentThread().getId() + "";
boolean isLock = demo.lock(id);
try {
// 拿到锁的话,就对共享参数减一
if (isLock) {
NUM--;
System.out.println(NUM);
}
} finally {
// 释放锁一定要注意放在finally
demo.unlock(id);
}
}).start();
}
}
}

我们创建100个线程来模拟并发的情况,执行后的结果是这样的:



可以看出,锁的效果达到了,线程安全是可以保证的。


当然,上面的代码只是简单的实现了效果,功能肯定是不完整的,一个健全的分布式锁要考虑的方面还有很多,实际设计起来不是那么容易的。


我们的目的只是为了学习和了解原理,手写一个工业级的分布式锁工具不现实,也没必要,类似的开源工具一大堆(Redisson),原理都差不多,而且早已经过业界同行的检验,直接拿来用就行。


虽然功能是实现了,但其实从设计上来说,这样的分布式锁存在着很大的缺陷,这也是本篇文章想重点探讨的内容,那到底存在哪些缺陷呢?


分布式锁的缺陷

一、客户端长时间阻塞导致锁失效问题


客户端1得到了锁,因为网络问题或者GC等原因导致长时间阻塞,然后业务程序还没执行完锁就过期了,这时候客户端2也能正常拿到锁,可能会导致线程安全的问题。


那么该如何防止这样的异常呢?我们先不说解决方案,介绍完其他的缺陷后再来讨论。


二、redis服务器时钟漂移问题


如果redis服务器的机器时钟发生了向前跳跃,就会导致这个key过早超时失效,比如说客户端1拿到锁后,key的过期时间是12:02分,但redis服务器本身的时钟比客户端快了2分钟,导致key在12:00的时候就失效了,这时候,如果客户端1还没有释放锁的话,就可能导致多个客户端同时持有同一把锁的问题。


三、单点实例安全问题


如果redis是单master模式的,当这台机宕机的时候,那么所有的客户端都获取不到锁了,为了提高可用性,可能就会给这个master加一个slave,但是因为redis的主从同步是异步进行的,可能会出现客户端1设置完锁后,master挂掉,slave提升为master,因为异步复制的特性,客户端1设置的锁丢失了,这时候客户端2设置锁也能够成功,导致客户端1和客户端2同时拥有锁。


为了解决Redis单点问题,redis的作者提出了RedLock算法。


RedLock算法

该算法的实现前提在于Redis必须是多节点部署的,可以有效防止单点故障,具体的实现思路是这样的:


1、获取当前时间戳(ms);


2、先设定key的有效时长(TTL),超出这个时间就会自动释放,然后client(客户端)尝试使用相同的key和value对所有redis实例进行设置,每次链接redis实例时设置一个比TTL短很多的超时时间,这是为了不要过长时间等待已经关闭的redis服务。并且试着获取下一个redis实例。


比如:TTL(也就是过期时间)为5s,那获取锁的超时时间就可以设置成50ms,所以如果50ms内无法获取锁,就放弃获取这个锁,从而尝试获取下个锁;


3、client通过获取所有能获取的锁后的时间减去第一步的时间,还有redis服务器的时钟漂移误差,然后这个时间差要小于TTL时间并且成功设置锁的实例数>= N/2 + 1(N为Redis实例的数量),那么加锁成功


比如TTL是5s,连接redis获取所有锁用了2s,然后再减去时钟漂移(假设误差是1s左右),那么锁的真正有效时长就只有2s了;


4、如果客户端由于某些原因获取锁失败,便会开始解锁所有redis实例。


根据这样的算法,我们假设有5个Redis实例的话,那么client只要获取其中3台以上的锁就算是成功了,用流程图演示大概就像这样:



好了,算法也介绍完了,从设计上看,毫无疑问,RedLock算法的思想主要是为了有效防止Redis单点故障的问题,而且在设计TTL的时候也考虑到了服务器时钟漂移的误差,让分布式锁的安全性提高了不少。


但事实真的是这样吗?反正我个人的话感觉效果一般般,


首先第一点,我们可以看到,在RedLock算法中,锁的有效时间会减去连接Redis实例的时长,如果这个过程因为网络问题导致耗时太长的话,那么最终留给锁的有效时长就会大大减少,客户端访问共享资源的时间很短,很可能程序处理的过程中锁就到期了。而且,锁的有效时间还需要减去服务器的时钟漂移,但是应该减多少合适呢,要是这个值设置不好,很容易出现问题。


然后第二点,这样的算法虽然考虑到用多节点来防止Redis单点故障的问题,但但如果有节点发生崩溃重启的话,还是有可能出现多个客户端同时获取锁的情况。


假设一共有5个Redis节点:A、B、C、D、E,客户端1和2分别加锁


客户端1成功锁住了A,B,C,获取锁成功(但D和E没有锁住)。
节点C的master挂了,然后锁还没同步到slave,slave升级为master后丢失了客户端1加的锁。
客户端2这个时候获取锁,锁住了C,D,E,获取锁成功。

这样,客户端1和客户端2就同时拿到了锁,程序安全的隐患依然存在。除此之外,如果这些节点里面某个节点发生了时间漂移的话,也有可能导致锁的安全问题。


所以说,虽然通过多实例的部署提高了可用性和可靠性,但RedLock并没有完全解决Redis单点故障存在的隐患,也没有解决时钟漂移、客户端长时间阻塞而导致的锁超时失效问题。


从这一点上看,RedLock算法也并没有保证锁的安全性。


结论

有人可能要进一步问了,那该怎么做才能保证锁的绝对安全呢?


对此我只能说,鱼和熊掌不可兼得,我们之所以用Redis作为分布式锁的工具,很大程度上是因为Redis本身效率高且单进程的特点,即使在高并发的情况下也能很好的保证性能,但很多时候,性能和安全不能完全兼顾,如果你一定要保证锁的安全性的话,可以用其他的中间件如db、zookeeper来做控制,这些工具能很好的保证锁的安全,但性能方面只能说是差强人意,否则大家早就用上了。


一般来说,用Redis控制共享资源并且还要求数据安全要求较高的话,最终的保底方案是对业务数据做幂等控制,这样一来,即使出现多个客户端获得锁的情况也不会影响数据的一致性。当然,也不是所有的场景都适合这么做,具体怎么取舍就需要各位看官自己处理啦,毕竟,没有完美的技术,只有适合的才是最好的。


如果您觉得文章有用的话,欢迎点个赞或转发支持一下,这将是对我创作的最好鼓励!


作者:鄙人薛某,一个不拘于技术的互联网人,喜欢用通俗易懂的语言来解构后端技术的知识点,想看更多精彩文章的可以关注我的公众号,微信搜索【鄙人薛某】即可关注


版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/yeya/p/14274948.html

随机推荐

webclient是什么意思_Web 是什么意思?

展开全部web是什么?首先简单的说Web就是为用户提供的一种在互联网32313133353236313431303231363533e58685e5aeb931333433656135上...

我要抢一个娘亲 阅读(389)

Facebook营销常犯的错误,看看你中招了吗?

Facebook营销常犯的错误,看看你中招了吗?

1、垃圾邮件大多数人都反感垃圾邮件,所以进行邮件营销时一定要注意,遵循能帮到客户什么,对他有价值,这样才会有回复。2、尊重别人的“墙”不要在别人...

fujiao0 阅读(933)