redis解决高并发分布式锁探讨--图灵学院听后感

   今天在图灵听了这么一节关于分布式的锁的问题,有些感触,用文章记录一下当时的收获

   先借课堂内的代码来分析课堂上面的问题,有错误的地方,或者有改进的地方 ,各位大佬探讨一下,因为看完开始写文章,没有自己去写代码,所以有看官见谅一下

   我会根据课堂上面老师说的一步一步写出来。先贴代码

  redis解决高并发分布式锁探讨--图灵学院听后感_第1张图片

首先介绍 里面要做的事情

这里是在redis里面加入了一个 stock的缓存 value为50

 

第一个问题,在分布式环境下,前端由nginx分发请求到后端服,分布式环境下,如何保证库存的原子性

1.首先错误出现,使用synchronized同步方法来进行保证原子性

出现问题有

1.在多台Tomcat服务器的时候,synchronized锁只是属于一个jvm的不能控制的了多台机器的原子性

例如:tomcat 2台机器同时进行访问 ,在8080进行删减库存的时候8090机器也在进行删减,这时候是无法控制导致数据错乱

redis解决高并发分布式锁探讨--图灵学院听后感_第2张图片

锁住的只是单台机器,但是数据是从缓存获取所以问题是在 synchronized锁所在的位置是不能控制redis的

解决方式:这里使用的是springboot封装的redis方法27行代码

原理呢,就是在访问redis数据之前,自己加入一个锁,如果这里拿不到锁则为false,就不会向下执行,根据返回值的result来判断,如果拿到锁了,那么就往下面执行,如果没拿到那么就直接retun掉,为了保证操作完后锁的释放,需要在后面加入finally代码块来释放锁形成闭环操作

2.第二个问题

就上面这种方式后继续提出的问题:如果说在加上锁,后面的代码还没有执行,服务器这时候宕机了,锁没有释放掉,别的请求到其他服务器上面,那么锁就会导致 “永久失效”

解决方式:上面28行代码,给锁加入一个超时时间,如果宕机了,锁到时间也能自动释放掉

这里也还有一个问题说明一下,这里redis会把所有的请求形成一个队列来排队访问,没有获取到锁的就重复的进行尝试获取锁,这样就不会让用户体验下降太多

3.第三个问题

其实不太理解第三问题为什么会出现,后续我会补全,这里就说明一下他们所说的产生原因

由第一个线程创建了锁后,第二个现在在创建锁的时候第一个执行完了,然后进行释放锁,那么第一个可能把第二个锁也给释放掉了

不解的是:既然是锁,第一个没有执行完,那么第二个应该等待而不是创建成功 第一个释放第二个才能创建

关键原因:是锁被他人所释放,应该只能由自己来释放

后面就加上了uuid为一个值,在释放锁的时候进行判断,只有当前创建锁的人来释放才可以

4.第四个问题

在执行第27,28行代码的时候,27行执行完就宕机了,后面超时还没有设置成功怎么办

关键原因:这里是2步操作不能保证原子性,所以这里使用的redis的一个框架,把2步操作合并成一步,内部来保证原子性

解决方式:看30行代码

5.第5个问题

如果我们设置的时候没有把控好,或者某个sql卡顿,某个代码执行时间过长,那么超过设定的超时,时间这时候锁被释放了,那么就会出现锁被提前释放,后面代码执行的不了。

解决方式:这里这个框架也给出了解决方式,在创建锁的同时,开启一个线程设定一个定时器,定义好时间来访问锁是否还在,如果在就进行续约操作,直至锁的释放

 从上面看代码是这次分享的最后的了,,最后看代码更改的那几个,是使用redis提供的框架内的方法整合了前面说的问题解决方式

 

你可能感兴趣的:(分布式)