最全说完 Redis 分布式锁,面试官对我竖起大拇指,华为java面试题目

最后

本人也收藏了一份Java面试核心知识点来应付面试,借着这次机会可以送给我的读者朋友们:

目录:

二面蚂蚁金服(交叉面),已拿offer,Java岗定级阿里P6

Java面试核心知识点

一共有30个专题,足够读者朋友们应付面试啦,也节省朋友们去到处搜刮资料自己整理的时间!

二面蚂蚁金服(交叉面),已拿offer,Java岗定级阿里P6

Java面试核心知识点

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

知道了原理后,我们就可以手写代码来实现 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 个线程来模拟并发的情况,执行后的结果是这样的:

说完 Redis 分布式锁,面试官对我竖起大拇指

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

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

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

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

分布式锁的缺陷

=======

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

===============

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

说完 Redis 分布式锁,面试官对我竖起大拇指

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

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 台以上的锁就算是成功了,用流程图演示大概就像这样:

说完 Redis 分布式锁,面试官对我竖起大拇指

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

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

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

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

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

总结

无论是哪家公司,都很重视高并发高可用的技术,重视基础,重视JVM。面试是一个双向选择的过程,不要抱着畏惧的心态去面试,不利于自己的发挥。同时看中的应该不止薪资,还要看你是不是真的喜欢这家公司,是不是能真的得到锻炼。其实我写了这么多,只是我自己的总结,并不一定适用于所有人,相信经过一些面试,大家都会有这些感触。

最后我整理了一些面试真题资料,技术知识点剖析教程,还有和广大同仁一起交流学习共同进步,还有一些职业经验的分享。

面试了阿里,滴滴,网易,蚂蚁,最终有幸去了网易【面试题分享】

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

多,只是我自己的总结,并不一定适用于所有人,相信经过一些面试,大家都会有这些感触。

最后我整理了一些面试真题资料,技术知识点剖析教程,还有和广大同仁一起交流学习共同进步,还有一些职业经验的分享。

[外链图片转存中…(img-A41WsDAx-1715614309918)]

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

  • 11
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值