锁的基本概念到Redis分布式锁实现

云计算 分布式 Redis
近来,分布式的问题被广泛提及,比如分布式事务、分布式框架、ZooKeeper、SpringCloud等等。

 近来,分布式的问题被广泛提及,比如分布式事务、分布式框架、ZooKeeper、SpringCloud等等。本文先回顾锁的概念,再介绍分布式锁,以及如何用Redis来实现分布式锁。

一、锁的基本了解

首先,回顾一下我们工作学习中的锁的概念。

为什么要先讲锁再讲分布式锁呢?

我们都清楚,锁的作用是要解决多线程对共享资源的访问而产生的线程安全问题,而在平时生活中用到锁的情况其实并不多,可能有些朋友对锁的概念和一些基本的使用不是很清楚,所以我们先看锁,再深入介绍分布式锁。

[[286783]]

通过一个卖票的小案例来看,比如大家去抢dota2 ti9门票,如果不加锁的话会出现什么问题?此时代码如下:

  1. package Thread; 
  2. import java.util.concurrent.TimeUnit; 
  3.  
  4. public class Ticket { 
  5.  
  6. /** 
  7. * 初始库存量 
  8. * */ 
  9. Integer ticketNum = 8
  10.  
  11. public void reduce(int num){ 
  12. //判断库存是否够用 
  13. if((ticketNum - num) >= 0){ 
  14. try { 
  15. TimeUnit.MILLISECONDS.sleep(200); 
  16. }catch (InterruptedException e){ 
  17. e.printStackTrace(); 
  18. ticketNum -= num; 
  19. System.out.println(Thread.currentThread().getName() + "成功卖出" 
  20. + num + "张,剩余" + ticketNum + "张票"); 
  21. }else { 
  22. System.err.println(Thread.currentThread().getName() + "没有卖出" 
  23. + num + "张,剩余" + ticketNum + "张票"); 
  24.  
  25. public static void main(String[] args) throws InterruptedException{ 
  26. Ticket ticket = new Ticket(); 
  27. //开启10个线程进行抢票,按理说应该有两个人抢不到票 
  28. for(int i=0;i<10;i++){ 
  29. new Thread(() -> ticket.reduce(1),"用户" + (i + 1)).start(); 
  30. Thread.sleep(1000L); 
  31.  

代码分析:这里有8张ti9门票,设置了10个线程(也就是模拟10个人)去并发抢票,如果抢成功了显示成功,抢失败的话显示失败。按理说应该有8个人抢成功了,2个人抢失败,下面来看运行结果:

Redis专题(3):锁的基本概念到Redis分布式锁实现

我们发现运行结果和预期的情况不一致,居然10个人都买到了票,也就是说出现了线程安全的问题,那么是什么原因导致的呢?

原因就是多个线程之间产生了时间差。

如图所示,只剩一张票了,但是两个线程都读到的票余量是1,也就是说线程B还没有等到线程A改库存就已经抢票成功了。

Redis专题(3):锁的基本概念到Redis分布式锁实现

  1. 怎么解决呢?想必大家都知道,加个synchronized关键字就可以了,在一个线程进行reduce方法的时候,其他线程则阻塞在等待队列中,这样就不会发生多个线程对共享变量的竞争问题。  
  2. 举个例子  
  3. 比如我们去健身房健身,如果好多人同时用一台机器,同时在一台跑步机上跑步,就会发生很大的问题,大家会打得不可开交。如果我们加一把锁在健身房门口,只有拿到锁的钥匙的人才可以进去锻炼,其他人在门外等候,这样就可以避免大家对健身器材的竞争。代码如下:  
  4. public  synchronized void reduce(int num){  
  5.         //判断库存是否够用  
  6.         if((ticketNum - num) >= 0){  
  7.             try {  
  8.                 TimeUnit.MILLISECONDS.sleep(200);  
  9.             }catch (InterruptedException e){  
  10.                 e.printStackTrace();  
  11.             }  
  12.             ticketNum -= num;  
  13.             System.out.println(Thread.currentThread().getName() + "成功卖出"  
  14.             + num + "张,剩余" + ticketNum + "张票");  
  15.         }else {  
  16.             System.err.println(Thread.currentThread().getName() + "没有卖出"  
  17.                     + num + "张,剩余" + ticketNum + "张票");  
  18.         }  
  19.     }  

运行结果:

Redis专题(3):锁的基本概念到Redis分布式锁实现

果不其然,结果有两个人没有成功抢到票,看来我们的目的达成了。

二、锁的性能优化

2.1 缩短锁的持有时间

事实上,按照我们对日常生活的理解,不可能整个健身房只有一个人在运动。所以我们只需要对某一台机器加锁就可以了,比如一个人在跑步,另一个人可以去做其他的运动。

对于票务系统来说,我们只需要对库存的修改操作的代码加锁就可以了,别的代码还是可以并行进行,这样会大大减少锁的持有时间,代码修改如下:

  1. public void reduceByLock(int num){ 
  2. boolean flag = false
  3. synchronized (ticketNum){ 
  4. if((ticketNum - num) >= 0){ 
  5. ticketNum -= num; 
  6. flag = true
  7. if(flag){ 
  8. System.out.println(Thread.currentThread().getName() + "成功卖出" 
  9. + num + "张,剩余" + ticketNum + "张票"); 
  10. else { 
  11. System.err.println(Thread.currentThread().getName() + "没有卖出" 
  12. + num + "张,剩余" + ticketNum + "张票"); 
  13. if(ticketNum == 0){ 
  14. System.out.println("耗时" + (System.currentTimeMillis() - startTime) + "毫秒"); 
  15.  
  16. 这样做的目的是充分利用cpu的资源,提高代码的执行效率。 
  17. 这里我们对两种方式的时间做个打印: 
  18. public synchronized void reduce(int num){ 
  19. //判断库存是否够用 
  20. if((ticketNum - num) >= 0){ 
  21. try { 
  22. TimeUnit.MILLISECONDS.sleep(200); 
  23. }catch (InterruptedException e){ 
  24. e.printStackTrace(); 
  25. ticketNum -= num; 
  26. if(ticketNum == 0){ 
  27. System.out.println("耗时" + (System.currentTimeMillis() - startTime) + "毫秒"); 
  28. System.out.println(Thread.currentThread().getName() + "成功卖出" 
  29. + num + "张,剩余" + ticketNum + "张票"); 
  30. }else { 
  31. System.err.println(Thread.currentThread().getName() + "没有卖出" 
  32. + num + "张,剩余" + ticketNum + "张票"); 

Redis专题(3):锁的基本概念到Redis分布式锁实现

Redis专题(3):锁的基本概念到Redis分布式锁实现

果然,只对部分代码加锁会大大提供代码的执行效率。

所以,在解决了线程安全的问题后,我们还要考虑到加锁之后的代码执行效率问题。

2.2 减少锁的粒度

举个例子,有两场电影,分别是最近刚上映的魔童哪吒和蜘蛛侠,我们模拟一个支付购买的过程,让方法等待,加了一个CountDownLatch的await方法,运行结果如下:

  1. package Thread; 
  2. import java.util.concurrent.CountDownLatch; 
  3.  
  4. public class Movie { 
  5. private final CountDownLatch latch = new CountDownLatch(1); 
  6. //魔童哪吒 
  7. private Integer babyTickets = 20
  8.  
  9. //蜘蛛侠 
  10. private Integer spiderTickets = 100
  11.  
  12. public synchronized void showBabyTickets() throws InterruptedException{ 
  13. System.out.println("魔童哪吒的剩余票数为:" + babyTickets); 
  14. //购买 
  15. latch.await(); 
  16.  
  17. public synchronized void showSpiderTickets() throws InterruptedException{ 
  18. System.out.println("蜘蛛侠的剩余票数为:" + spiderTickets); 
  19. //购买 
  20.  
  21. public static void main(String[] args) { 
  22. Movie movie = new Movie(); 
  23. new Thread(() -> { 
  24. try { 
  25. movie.showBabyTickets(); 
  26. }catch (InterruptedException e){ 
  27. e.printStackTrace(); 
  28. },"用户A").start(); 
  29.  
  30. new Thread(() -> { 
  31. try { 
  32. movie.showSpiderTickets(); 
  33. }catch (InterruptedException e){ 
  34. e.printStackTrace(); 
  35. },"用户B").start(); 
  36.  

执行结果:

魔童哪吒的剩余票数为:20

我们发现买哪吒票的时候阻塞会影响蜘蛛侠票的购买,而实际上,这两场电影之间是相互独立的,所以我们需要减少锁的粒度,将movie整个对象的锁变为两个全局变量的锁,修改代码如下:

  1. public void showBabyTickets() throws InterruptedException{ 
  2. synchronized (babyTickets) { 
  3. System.out.println("魔童哪吒的剩余票数为:" + babyTickets); 
  4. //购买 
  5. latch.await(); 
  6. public void showSpiderTickets() throws InterruptedException{ 
  7. synchronized (spiderTickets) { 
  8. System.out.println("蜘蛛侠的剩余票数为:" + spiderTickets); 
  9. //购买 

 

执行结果:

魔童哪吒的剩余票数为:20

蜘蛛侠的剩余票数为:100

现在两场电影的购票不会互相影响了,这就是第二个优化锁的方式:减少锁的粒度。顺便提一句,Java并发包里的ConcurrentHashMap就是把一把大锁变成了16把小锁,通过分段锁的方式达到高效的并发安全。

2.3 锁分离

锁分离就是常说的读写分离,我们把锁分成读锁和写锁,读的锁不需要阻塞,而写的锁要考虑并发问题。

三、锁的种类

  • 公平锁:ReentrantLock
  • 非公平锁:Synchronized、ReentrantLock、cas
  • 悲观锁:Synchronized
  • 乐观锁:cas
  • 独享锁:Synchronized、ReentrantLock
  • 共享锁:Semaphore

这里就不一一讲述每一种锁的概念了,大家可以自己学习,锁还可以按照偏向锁、轻量级锁、重量级锁来分类。

四、Redis分布式锁

了解了锁的基本概念和锁的优化后,重点介绍分布式锁的概念。

Redis专题(3):锁的基本概念到Redis分布式锁实现

上图所示是我们搭建的分布式环境,有三个购票项目,对应一个库存,每一个系统会有多个线程,和上文一样,对库存的修改操作加上锁,能不能保证这6个线程的线程安全呢?

当然是不能的,因为每一个购票系统都有各自的JVM进程,互相独立,所以加synchronized只能保证一个系统的线程安全,并不能保证分布式的线程安全。

所以需要对于三个系统都是公共的一个中间件来解决这个问题。

这里我们选择Redis来作为分布式锁,多个系统在Redis中set同一个key,只有key不存在的时候,才能设置成功,并且该key会对应其中一个系统的唯一标识,当该系统访问资源结束后,将key删除,则达到了释放锁的目的。

4.1 分布式锁需要注意哪些点

1)互斥性

在任意时刻只有一个客户端可以获取锁。

这个很容易理解,所有的系统中只能有一个系统持有锁。

2)防死锁

假如一个客户端在持有锁的时候崩溃了,没有释放锁,那么别的客户端无法获得锁,则会造成死锁,所以要保证客户端一定会释放锁。

Redis中我们可以设置锁的过期时间来保证不会发生死锁。

3)持锁人解锁

解铃还须系铃人,加锁和解锁必须是同一个客户端,客户端A的线程加的锁必须是客户端A的线程来解锁,客户端不能解开别的客户端的锁。

4)可重入

当一个客户端获取对象锁之后,这个客户端可以再次获取这个对象上的锁。

4.2 Redis分布式锁流程

Redis专题(3):锁的基本概念到Redis分布式锁实现

Redis分布式锁的具体流程:

1)首先利用Redis缓存的性质在Redis中设置一个key-value形式的键值对,key就是锁的名称,然后客户端的多个线程去竞争锁,竞争成功的话将value设为客户端的唯一标识。

2)竞争到锁的客户端要做两件事:

  • 设置锁的有效时间 目的是防死锁 (非常关键)

需要根据业务需要,不断的压力测试来决定有效期的长短。

  • 分配客户端的唯一标识,目的是保证持锁人解锁(非常重要)

所以这里的value就设置成唯一标识(比如uuid)。

3)访问共享资源

4)释放锁,释放锁有两种方式,第一种是有效期结束后自动释放锁,第二种是先根据唯一标识判断自己是否有释放锁的权限,如果标识正确则释放锁。

4.3 加锁和解锁

4.3.1 加锁

1)setnx命令加锁

set if not exists 我们会用到Redis的命令setnx,setnx的含义就是只有锁不存在的情况下才会设置成功。

2)设置锁的有效时间,防止死锁 expire

加锁需要两步操作,思考一下会有什么问题吗?

假如我们加锁完之后客户端突然挂了呢?那么这个锁就会成为一个没有有效期的锁,接着就可能发生死锁。虽然这种情况发生的概率很小,但是一旦出现问题会很严重,所以我们也要把这两步合为一步。

幸运的是,Redis3.0已经把这两个指令合在一起成为一个新的指令。

来看jedis的官方文档中的源码:

  1. public String set(String key, String value, String nxxx, String expx, long time) { 
  2. this.checkIsInMultiOrPipeline(); 
  3. this.client.set(key, value, nxxx, expx, time); 
  4. return this.client.getStatusCodeReply(); 

 

这就是我们想要的!

4.3.2 解锁

  1. 检查是否自己持有锁(判断唯一标识);
  2. 删除锁。

解锁也是两步,同样也要保证解锁的原子性,把两步合为一步。

这就无法借助于Redis了,只能依靠Lua脚本来实现。

  1. if Redis.call("get",key==argv[1])then 
  2. return Redis.call("del",key) 
  3. else return 0 end 

 

这就是一段判断是否自己持有锁并释放锁的Lua脚本。

为什么Lua脚本是原子性呢?因为Lua脚本是jedis用eval()函数执行的,如果执行则会全部执行完成。

五、Redis分布式锁代码实现

  1. public class RedisDistributedLock implements Lock { 
  2. //上下文,保存当前锁的持有人id 
  3. private ThreadLocal<String> lockContext = new ThreadLocal<String>(); 
  4.  
  5. //默认锁的超时时间 
  6. private long time = 100
  7.  
  8. //可重入性 
  9. private Thread ownerThread; 
  10.  
  11. public RedisDistributedLock() { 
  12.  
  13. public void lock() { 
  14. while (!tryLock()){ 
  15. try { 
  16. Thread.sleep(100); 
  17. }catch (InterruptedException e){ 
  18. e.printStackTrace(); 
  19.  
  20. public boolean tryLock() { 
  21. return tryLock(time,TimeUnit.MILLISECONDS); 
  22.  
  23. public boolean tryLock(long time, TimeUnit unit){ 
  24. String id = UUID.randomUUID().toString(); //每一个锁的持有人都分配一个唯一的id 
  25. Thread t = Thread.currentThread(); 
  26. Jedis jedis = new Jedis("127.0.0.1",6379); 
  27. //只有锁不存在的时候加锁并设置锁的有效时间 
  28. if("OK".equals(jedis.set("lock",id, "NX""PX", unit.toMillis(time)))){ 
  29. //持有锁的人的id 
  30. lockContext.set(id); ① 
  31. //记录当前的线程 
  32. setOwnerThread(t); ② 
  33. return true
  34. }else if(ownerThread == t){ 
  35. //因为锁是可重入的,所以需要判断当前线程已经持有锁的情况 
  36. return true
  37. }else { 
  38. return false
  39.  
  40. private void setOwnerThread(Thread t){ 
  41. this.ownerThread = t; 
  42.  
  43. public void unlock() { 
  44. String script = null
  45. try
  46. Jedis jedis = new Jedis("127.0.0.1",6379); 
  47. script = inputStream2String(getClass().getResourceAsStream("/Redis.Lua")); 
  48. if(lockContext.get()==null){ 
  49. //没有人持有锁 
  50. return
  51. //删除锁 ③ 
  52. jedis.eval(script, Arrays.asList("lock"), Arrays.asList(lockContext.get())); 
  53. lockContext.remove(); 
  54. }catch (Exception e){ 
  55. e.printStackTrace(); 
  56.  
  57. /** 
  58. * 将InputStream转化成String 
  59. * @param is 
  60. * @return 
  61. * @throws IOException 
  62. */ 
  63. public String inputStream2String(InputStream is) throws IOException { 
  64. ByteArrayOutputStream baos = new ByteArrayOutputStream(); 
  65. int i = -1
  66. while ((i = is.read()) != -1) { 
  67. baos.write(i); 
  68. return baos.toString(); 
  69.  
  70. public void lockInterruptibly() throws InterruptedException { 
  71.  
  72.  
  73. public Condition newCondition() { 
  74. return null
  • 用一个上下文全局变量来记录持有锁的人的uuid,解锁的时候需要将该uuid作为参数传入Lua脚本中,来判断是否可以解锁。
  • 要记录当前线程,来实现分布式锁的重入性,如果是当前线程持有锁的话,也属于加锁成功。
  • 用eval函数来执行Lua脚本,保证解锁时的原子性。

六、分布式锁的对比

6.1 基于数据库的分布式锁

1)实现方式

获取锁的时候插入一条数据,解锁时删除数据。

2)缺点

  • 数据库如果挂掉会导致业务系统不可用。
  • 无法设置过期时间,会造成死锁。

6.2 基于zookeeper的分布式锁

1)实现方式

加锁时在指定节点的目录下创建一个新节点,释放锁的时候删除这个临时节点。因为有心跳检测的存在,所以不会发生死锁,更加安全。

2)缺点

性能一般,没有Redis高效。

所以:

  • 从性能角度: Redis > zookeeper > 数据库 
  • 从可靠性(安全)性角度: zookeeper > Redis > 数据库

七、总结

本文从锁的基本概念出发,提出多线程访问共享资源会出现的线程安全问题,然后通过加锁的方式去解决线程安全的问题,这个方法会性能会下降,需要通过:缩短锁的持有时间、减小锁的粒度、锁分离三种方式去优化锁。

之后介绍了分布式锁的4个特点:

  • 互斥性 
  • 防死锁 
  • 加锁人解锁 
  • 可重入性

然后用Redis实现了分布式锁,加锁的时候用到了Redis的命令去加锁,解锁的时候则借助了Lua脚本来保证原子性。

最后对比了三种分布式锁的优缺点和使用场景。

希望大家对分布式锁有新的理解,也希望大家在考虑解决问题的同时要多想想性能的问题。

【本文是51CTO专栏机构宜信技术学院的原创文章,微信公众号“宜信技术学院( id: CE_TECH)”】

戳这里,看该作者更多好文

 

 

责任编辑:张燕妮 来源: 宜信技术学院
相关推荐

2022-01-06 10:58:07

Redis数据分布式锁

2023-08-21 19:10:34

Redis分布式

2019-02-26 09:51:52

分布式锁RedisZookeeper

2019-06-19 15:40:06

分布式锁RedisJava

2023-03-01 08:07:51

2020-07-16 20:55:19

ElasticSear集群分布式

2020-07-30 09:35:09

Redis分布式锁数据库

2020-07-15 16:50:57

Spring BootRedisJava

2023-10-11 09:37:54

Redis分布式系统

2022-06-16 08:01:24

redis分布式锁

2021-10-25 10:21:59

ZK分布式锁ZooKeeper

2021-02-28 07:49:28

Zookeeper分布式

2017-01-16 14:13:37

分布式数据库

2018-04-03 16:24:34

分布式方式

2017-04-13 10:51:09

Consul分布式

2022-04-08 08:27:08

分布式锁系统

2022-03-04 09:54:04

Redis分布式锁脚本

2023-01-13 07:39:07

2020-11-16 12:55:41

Redis分布式锁Zookeeper

2022-09-19 08:17:09

Redis分布式
点赞
收藏

51CTO技术栈公众号