微服务架构之:Redis分布式锁

在集群架构下,传统的synchronized无法解决并发问题。分布式锁通过在JVM外部设置锁监视器,实现多JVM环境下的线程互斥。Redis提供了set命令实现互斥锁,并通过EX参数确保原子性。为防止因Redis宕机导致的死锁,需设置锁的过期时间。文章介绍了基于Redis的分布式锁实现,包括获取和释放锁的方法。
摘要由CSDN通过智能技术生成

Redis分布式锁

    • 分布式锁的实现原理和不同方式的实现对比
    • 基于Redis实现的分布式锁

集群架构下的并发问题

在单体架构上,乐观锁和悲观锁可以锁住并发情况下的同步代码块,我们多使用synchronized来对方法加锁。但是在配上负载均衡的集群模式下, 普通的synchronized是无法锁住从两台服务器同时进入的请求 。

这是在了解秒杀项目的难点之一: 一人一单的并发安全问题 在使用集群架构出现的难点。我们先从 单体项目 出发,单体项目很好理解,假如有俩线程:线程1查询订单,判断是否存在。然后第二个线程之后在去查询订单,判断是否存在,在synchronized的作用下两个线程是不会发生问题的。

那现在,我们不再是一台服务器,而是多台。在当前这一个JVM内部,锁的原理是在JVM内部维护了一个 锁监视器对象 ,监视器的对象用的是userId,它是在我们的 常量池 里面。那么在这个JVM内部是维护了这一个常量池子,当ID相同的情况下,他们永远都是同一个锁,也就是说锁的监视器是同一个。所以无论是线程1也好,线程2也好,他们俩要获取锁的时候,锁监视器就会记录线程ID,当另一个线程再来获取锁的时候肯定是不行的,因为锁监视器已经记录一个了。

但是,当

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值