对于很多系统而言,都有集群处理。在集群中使用quartz或者task处理任务的时候,一般有三种选择:
创新互联公司于2013年成立,是专业互联网技术服务公司,拥有项目做网站、网站建设网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元十堰郧阳做网站,已为上家服务,为十堰郧阳各地企业和个人服务,联系电话:18980820575
1. 多实例顺序执行
2. 单实例执行
3. 多实例并行执行
创保目前考虑的是1情况。
redis对于并发较小的情况下,进行锁控制,效果是较为理想的。目前创保只有八台实例,适用于该方案。
1. 首先,redis提供了一个setnx方法,该方法执行后会返回key值在设置之前是否存在。
这是进行并发控制的基础,但并不够。
2. 在利用 setnx 进行 key 值设定后,如果instance发生异常(不仅仅是exception)会导致该锁无法正常释放。
所以,我们需要为锁设置一个失效时间,即expire命令。
1. 问题描述
并发竞争key这个问题简单讲就是:
同时有多个客户端去set一个key。
示例场景 1
例如有多个请求一起去对某个商品减库存,通常操作流程是:
假设当前库存值为 20,现在有2个连接都要减 5,结果库存值应该是 10 才对,但存在下面这种情况:
示例场景 2
比如有3个请求有序的修改某个key,按正常顺序的话,数据版本应该是 1->2->3,最后应该是 3。
但如果第二个请求由于网络原因迟到了,数据版本就变为了 1->3->2,最后值为 2,出问题了。
1.Redis写入是单线程的,单个命令执行不存在并发问题
2.如果是get命令,然后判断再进行set,那就有并发问题,set值不正确,举例:库存系统,get库存大于零,则库存减一再set库存,并发条件下,get得到的库存有可能是一样的,所以set回去的库存也是一样的,所以库存少减了,导致商品实际库存不足,多卖的情况,秒杀活动那就会比较危险了
3.解决办法,加入一个分布式锁
redis 本身是单进程、单线程的模型,就是说一个时刻就只能有一个东东在执行,不管是多少个命令,只能是串行执行,因此从这个意义上保证了单个命令执行的多线程(多个客户端操作)的安全,也就是不管有多少个客户端在发请求,redis每次只能执行一个客户端的命令,不存在多线程。
但是redis对于多个客户端的多个命令,并不能保证其线程安全性,比如有一个值x=1;如果ClientA 获取x的值,x=x+1,然后再设置回去;在此期间,有一个ClientB做同样的操作;如果ClientA、ClientB的操作被串行了,那么x=3;但是多个命令之间不能保证(除非是增加了所谓的锁之类的东东),从而x的值就不一定是3了,这个时候就存在了并发操作的问题。
当然redis也考虑到了相关的情况,提供了incr之类的原子操作命令,保证了多线程并发操作的安全性;
对于同一个客户的多次点击操作,如果不做区分,可能就存在问题,比如支付宝的种树浇水这个操作,如果不做控制,一个用户快速的多次点击,可能就会超过3次(支付宝限制一天只能帮某个好友浇水3次),这个时候其实有简单的解决方法:比如每次浇水有一个浇水ID,第1、2、3次都有一个不同的ID,从第4次开始的操作其ID还是设置为3(由客户端来限制),那么后台只要判断ID是否重复,就可以做过滤; 同样的问题在第三方API对接的时候也存在(比如调用支付宝付款,有时候网络不好,是否会存在多次付费问题?),此时我想每个支付的请求也带了一个唯一的ID,保证了支付的唯一性(当然可能还会有对用户名、支付款项的验证--银行支付的时候往往会提醒你,你支付了一笔同样的款项,需要确认--具体的场景是你需要支付某人1000块,你分成500、500两笔,此时网银操作是会提醒你的);
因此对于相同的2个请求,如果是一种幂等的操作--比如都是get某个值(不会变的),那么其实处不处理看策略,至少不会造成不一致;对于支付这样的行为,肯定需要做判断确定是同一个请求,对另外一个请求做过滤。
到此,以上就是小编对于redis 并发锁的问题就介绍到这了,希望这1点解答对大家有用。
网站栏目:redis如何防止并发?(redis怎么实现并发锁)
本文网址:http://www.gawzjz.com/qtweb2/news4/11204.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联