Spring Boot 整合——Redis分布式锁的简单实现

共享的数据

当我们的系统在一起的时候,假如去操作共享的数据的时候,我们可以加锁来保证数据的安全。但是当我们系统被拆分成多个服务,或者不同的系统去共享一部分数据,而此数据可以被多个系统修改的时候,比如多个系统去修改一个订单的信息。为了保证数据的可靠,我们需要在分布式或者多系统之间找出一种锁的实现方式。

而在分布式系统中实现锁的途径有多种。这里我们先讲Reids的方式。

首先要声明的本例子使用的版本信息

 <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.8.RELEASE</version>
        <relativePath/> 
    </parent>

另外本例子只是一个很简单的实现,并没有实现锁的重入。

锁的基本要求

我们要实现一个锁,一般来说要保证以下要求;

  1. 互斥,同一时间我们需要保证只有一个(线程)客户端能够获取到锁。
  2. 避免死锁,我们需要尽量避免出现死锁,当持有锁的客户端崩溃的时候,需要有其他方式使锁被释放。
  3. 客户端只能解锁自己的锁,不能去解锁别人的锁。

上面的要求就需要我们保证代码在设置并且判断是否有值的时候需要原子操作,以及锁需要有个时间、保证锁最终可以成功释放掉。

分布式锁的运作

假设两个系统都是订单处理系统,现在都去订单系统中拉取订单进行处理。这个时候可能存在APP1和APP2都拉取一个订单进行处理。这样就可能出现重复处理。

APP1
订单
APP2

那么我们现在在订单之前加一个获取锁的操作

APP1
APP2
订单

此时我们APP1 优先请求订单1的锁,此时APP2再去申请订单1的锁会被拒绝。这样就避免重复操作。

拿到订单1的锁
申请订单1锁失败,转去操作别的订单
APP1
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大·风

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值