使用redis分布式锁解决并发线程资源共享问题_多个线程获取到同一把分布式锁 - CSDN文库

182 浏览量更新于2023-05-04 评论收藏 77KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

使用使用redis分布式锁解决并发线程资源共享问题分布式锁解决并发线程资源共享问题

前言前言

众所周知, 在多线程中，因为共享全局变量,会导致资源修改结果不一致，所以需要加锁来解决这个问题，保证同一时间只有一个线程对资源进行操作

但是在分布式架构中，我们的服务可能会有n个实例，但线程锁只对同一个实例有效，就需要用到分布式锁—-redis setnx

原理原理

修改某个资源时, 在redis中设置一个key，value根据实际情况自行决定如何表示

我们既然要通过检查key是否存在（存在表示有线程在修改资源，资源上锁，其他线程不可同时操作，若key不存在，表示资源未被线程占用，允许线程抢占，然后

将通过setnx设置vlaue，表示资源上锁，其他线程不可同时操作）

图示：

分析分析

我们的服务处于一个集群中，如果只是简单的的使用线程锁来解决以上问题，是存在问题的：因为线程是基于进程的，两个web server处于不同的进程空间

也就是说,user1的请求发往web server1，那只能与web server1的其他请求进行锁的操作，而不能对web server2的请求产生影响

上面的图中，user1发往web server1的请求负责处理的线程为Thread1,同理负责处理user2发往web server2的请求的线程thread2

在同一时刻1，两个线程都读取了mysql中residue_ticket的值为100，对应上图 (1)(2)，各自对100进行-1操作，更新到数据库，对应(3)(4)

我们预期的情况是residue_ticket值被减少了两次，应该为98,但是实际情况下，两个线程都做了100-1=99的操作，并都将mysql中的值改为了99, 的这就会导致最终

数据不一致，所以就要用到分布式锁。

为什么用为什么用redis?

因为redis是单线程的，不存在多线程资源竞争，并且它真的很快

为什么用为什么用setnx 而不是而不是set?

setnx表示只有在key不存在时才能设置成功，但是set会在key存在的情况下修改value

利用setnx的特性，我们可以这样这样设计:

伪代码伪代码:

# 设置redis锁的

　　redis key = 'residue_ticket_lock'

　　# get_ticket是处理购票的逻辑

　　def get_ticket()：

　　　　time_out = 5 # 为了防止线程过多，当前线程获取不到锁，长时间处于循环中而导致的性能影响，我们设置一个超时时间，如果当前线程在超时时间内还

没有抢占到分布式锁，就返回失败的结果

　　　　while True:

　　　　　　　if redis.setnx('residue_ticket_lock'，'lock',5):

　　　　　　　　　　# 如果setnx返回True, 表示此刻没有其他线程在操作数据库,当前线程可以上锁成功,注意不仅设置了value=lock,还设置了过期时间，这是必要

的，为了防止上锁的线程异常崩掉导致不能释放(删除key)而导致其他所有线程永远拿不到操作权

　　　　　　　　　 residue_ticket = mysql.get('residue_ticket') # 从mysql中获取当前剩余票数

　　　　　　　　　 mysql.update('residue_ticket',residue_ticket-1) # 订购成功，将票数-1，更新数据到mysql

　　　　　　　　　　# 删除key，释放锁

　　　　　　　　　　redis.del('residue_ticket')

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余1页未读，立即下载

评论0

weixin_38536267

粉丝: 2
资源: 942

会员权益专享

图片转文字

全年可省5，000元立即开通

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈