一、分布式锁场景
1、互联网秒杀
2、抢优惠券
3、接口幂等性校验
二、扣减库存实战
1、不加锁版本
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.0.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<modelVersion>4.0.0</modelVersion>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.6.5</version>
</dependency>
</dependencies>
server:
port: 8080
spring:
redis:
database: 0
timeout: 3000
host: 192.168.131.171
port: 6380
package com.jihu.redis;
import org.redisson.Redisson;
import org.redisson.config.Config;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
@SpringBootApplication
public class RedisApplication {
public static void main(String[] args) {
SpringApplication.run(RedisApplication.class, args);
}
// 注意要注入redisson 否则会出错
@Bean
public Redisson redisson() {
Config config = new Config();
config.useSingleServer().setAddress("redis://192.168.131.171:6380").setDatabase(0);
return (Redisson) Redisson.create(config);
}
}
直接上代码,我们模拟一个扣减库存的简单场景。
【初始版本】
package com.jihu.redis.lock;
import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
@RestController
public class StockController {
@Autowired
private Redisson redisson;
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 模拟减库存
* @return ""
*/
@RequestMapping("/deduct_stock")
public String deductStock() {
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
return "end";
}
}
这样扣减库存的代码,如果我们直接部署到生产环境,会不会出问题?
我们来分析一下,假如现在是高并发的场景,用户需要秒杀抢一些商品。
问题分析
当大量请求同时去执行从Redis获取数据这一行代码的时候:
/ 从redis获取库存数量,此时值设置为50
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
此时由于我们没有任何的同步措施,这些请求都会直接从Redis中获取数据,查询到的结果自然就都是50了。
然后判断49大于0,然后都减1,库存剩余都是49.
然后都调用下面的代码将库存设置到Redis中,并且设置的值都是49.
stringRedisTemplate.opsForValue().set("stock", realStock + "");
但是这样显然不对呀!如果我是5个请求同时进来,都执行了减库存,库存应该是45呀,现在竟然还是49了!这样就会产生超卖的问题!
2、改进:加JVM锁
我们从上面的代码中分析得知,之所以会发生超卖,是因为我们读取Redis库存、扣减库存和将扣减后库存设置到Redis中的这些操作不是原子的,所以导致了超卖问题的产生。
【改进方案一:加JVM锁】
我们可以给以上操作库存的的操作加锁,从而实现原子性操作,这样应该可以避免超卖问题吧!于是乎,我们使用Synchronized来加锁:
package com.jihu.redis.lock;
import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
@RestController
public class StockController {
@Autowired
private Redisson redisson;
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 模拟减库存
* @return ""
*/
@RequestMapping("/deduct_stock")
public String deductStock() {
// 将操作库存的操作放到同步块中
synchronized (this) {
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
}
return "end";
}
}
分析,这样当多个请求执行进来的时候,线程会原子性的执行同步块中的扣减库存操作,可以防止超卖问题的产生。
问题分析
这样的加锁处理,在单机环境
下,确实没什么问题,可以防止超卖情况的发生。
但是,现在的互联网公司基本都是集群架构
,后端会存在多个服务实例。如果我们还是这样来使用JVM级别的锁,还能防止超卖情况的发生吗?
显然是不能的。因为JVM锁只能锁住同一个JVM进程中的线程,分布式集群架构下,请求往往是跨多个JVM进程的。
如下图,如果有两个tomcat同时去Redis查库存,Synchronized同步块只能锁住自己JVM中的并发请求,那另一台JVM中的请求是无法锁住的。这样依然会产生,多个请求同时去Redis查库存的情况。查询后发现都是50,都减去一个库存,然后都把49写入到Redis中,这样就产生了超卖的问题。
那在这样分布式的场景下,我们又该如何的解决超卖问题的?
此时我们需要一把分布式锁
!
何为分布式锁,就是可以锁住不同JVM进程的锁,可以使用Redis、zookeeper等实现。原理就是,多个JVM都可以或都需要访问这些第三方中间件,这样Redis或zooKeeper就相当于一个管理者,可以对不同的JVM请求进行管理。这样就达到了管理多个JVM中请求的功能了。
超卖测试
1、我们先启动端口为8080的服务;
2、修改端口为8090,然后修改IDEA,在Allow parallel run打钩,这样基于可以启动多个服务实例了,只是运行在不同端口。我们启动8080和8090的服务;
# 配置Redis分发(我使用的是windows本机的nginx)
upstream redislock {
server 127.0.0.1:8080 weight=1;
server 127.0.0.1:8090 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
proxy_pass http://redislock;
}
}
4、配置好之后,确保执行http://localhost/deduct_stock之后,8080和8090都可以接收到转发的请求:
5、随后我们使用jmeter进行压测准备:
我们配置200个请求,为了模拟高并发,在0s内发完;并且持续4轮;即总共会压800个请求。
压测地址:http://localhost/deduct_stock
6、开始压测
等待压测成功后,我们来分别查看8080和8090两个服务的日志。
我们来思考:如果两个日志打印出的 剩余库存的值有相同的,那么就以为着可能会发生超卖!
首先看8080的日志:
然后看8090的日志:
很明显的看到,两个日志中的剩余库存出现了大量相同的数字,这意味着已经发生了超卖的情况!!!
3、改进:加分布式锁
【改进方案二:加分布式锁】
三、Redis分布式锁实现
1、Setnx实现分布式锁
【setnx基础版本】存在问题!
package com.jihu.redis.lock;
import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class StockController {
@Autowired
private Redisson redisson;
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 模拟减库存
* @return ""
*/
@RequestMapping("/deduct_stock")
public String deductStock() {
String lockKey = "lockKey";
// setIfAbsent 相当于jedis.setnx(key, value)操作
/**
* setnx(lockKey, value):
*
* 如果这个lockKey在Redis中是已经存在的,则这条命令不做任何操作,返回false
* 如果这个lockey不存在于Redis中,则设置成功,并返回true
*
* 此时如果多个请求来执行这个命令,会在Redis中排队,此时只会有一个请求成功设置了lockKey并返回true.
* 生育的请求查询发现这个lockKey已经存在了,会直接返回false,不进行任何操作
*/
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "xiaoyan");
// ========= setnx 竞争锁失败 ==========
if (!result) {
return "{code: 10001, message:请重新再试!}";
}
// ========== setnx 竞争锁成功 =======
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
// 相当于jedis.set(key, value)
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
// 成功扣减库存后的请求,需要释放这个lockKey
stringRedisTemplate.delete(lockKey);
return "end";
}
}
我们这样使用setnx命令来实现Redis分布式锁,现在只会有一个请求使用setnx设置lockKey成功,然后执行扣减库存操作,然后删除lockKey. 剩余的请求竞争失败的会直接返回false。
那现在这样还存在其他问题吗?大家思考一下?如果执行扣减库存的时候抛出异常了呢?这样lockKey的锁岂不是永远都不会被释放了?
如果服务宕机了?该怎么删除lockKey呢 ?
所以说对于上面的问题,我们必须优化一下:
1、使用finally块来删除lockKey;
2、给setnx设置的lockKey添加过期时间。
【setnx升级版本】依然存在问题!
package com.jihu.redis.lock;
import org.redisson.Redisson;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class StockController {
@Autowired
private Redisson redisson;
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 模拟减库存
* @return ""
*/
@RequestMapping("/deduct_stock")
public String deductStock() {
String lockKey = "lockKey";
try {
// setIfAbsent 相当于jedis.setnx(key, value)操作
/**
* setnx(lockKey, value):
*
* 如果这个lockKey在Redis中是已经存在的,则这条命令不做任何操作,返回false
* 如果这个lockey不存在于Redis中,则设置成功,并返回true
*
* 此时如果多个请求来执行这个命令,会在Redis中排队,此时只会有一个请求成功设置了lockKey并返回true.
* 生育的请求查询发现这个lockKey已经存在了,会直接返回false,不进行任何操作
*/
// Redis内部会原子性的保证设置value和设置过期时间同时成功。
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "xiaoyan", 10, TimeUnit.SECONDS);
// 添加过期时间,防止服务宕机后无法删除
// 这是错误的设置过期的方式!!!如果服务还没执行到这行就宕机了,依然会无法释放锁!Redis过期时间一定要在set数据的时候就设置!!!
// stringRedisTemplate.expire(lockKey, 10, TimeUnit.SECONDS);
// ========= setnx 竞争锁失败 ==========
if (!result) {
return "{code: 10001, message:请重新再试!}";
}
// ========== setnx 竞争锁成功 =======
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
// 相当于jedis.set(key, value)
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
} finally { // 防止异常导致锁无法释放!!!
// 成功扣减库存后的请求,需要释放这个lockKey
stringRedisTemplate.delete(lockKey);
}
return "end";
}
}
注意,设置过期时间的时候,一定要和set值一起设置,让Redis原子性的去执行这个两个命令!
注意这个自动过期的时间设置,我们现在设置的是10s,即如果超过10s没有释放,Redis会自动释放。
我们这样设置完,好像各种情况都考虑到了!
那么,大家仔细再思考,是否还存在其他问题呢?
在一般的软件公司下,这样确实可以应对并发减库存的问题。
那么问题来了,在大型互联网公司中,如果此时的并发量非常大,大家想有没有可能存在这样的问题。我的一个请求成功竞争到了lockKey, 但是在执行扣减库存的业务的时候由于某些原因,导致执行的时间超过了10s.
这时候,Redis会自动释放这个lockKey的锁,但是我的这个请求并没有执行完扣减库存的业务呀。这时候其他请求也进入到扣减库存的业务代码中来。此时第一个请求还没来得及将扣减后的库存写回到Redis中,新的请求却体检查询了Redis数据库,这样一来,直接导致库存数量不准确,一定会产生超卖!!!
并且,如果第二个请求执行的过程中,第一个请求恰好执行15s结束,执行finally块中的删除lockKey,这样就会把第二个请求加的lockKey给删除掉。这样就会出现一个问题,某个请求的锁好像加成功了,一会又失败了。这样已经存在了很多问题…
我们来分析此时的问题,因为第一个请求扣减库存的时间太长,导致加的锁过期,从而新的请求可以加锁成功,而新的请求执行扣减库存的过程中,第一个请求恰好执行完,然后再finally块中释放了锁。但事实上,这个锁是第二个请求加的,不再是第一个请求的锁了。因为第一个请求的锁已经因为过期被Redis自己释放了。
总结来说:现在的问题是,不同的请求都可以操作同一个lockKey。所以,我们要思考,是否可以给每一个请求一个不同的lockkey,从而使得每一个请求只能自己加锁、解锁
。
我们只是只是用了一个lockKey,那么我们现在可以针对每一个请求都生成一个lockKey:
【setnx最终版本】可用
@RequestMapping("/deduct_stock")
public String deductStock() {
String lockKey = "lockKey";
String clientId = UUID.randomUUID().toString();
try {
// setIfAbsent 相当于jedis.setnx(key, value)操作
/**
* setnx(lockKey, value):
*
* 如果这个lockKey在Redis中是已经存在的,则这条命令不做任何操作,返回false
* 如果这个lockey不存在于Redis中,则设置成功,并返回true
*
* 此时如果多个请求来执行这个命令,会在Redis中排队,此时只会有一个请求成功设置了lockKey并返回true.
* 生育的请求查询发现这个lockKey已经存在了,会直接返回false,不进行任何操作
*/
// Redis内部会原子性的保证设置value和设置过期时间同时成功。
// clientId: 每一个请求都生成一个clientId, 这样只有自己才能释放锁
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);
// 添加过期时间,防止服务宕机后无法删除
// 这是错误的设置过期的方式!!!如果服务还没执行到这行就宕机了,依然会无法释放锁!Redis过期时间一定要在set数据的时候就设置!!!
// stringRedisTemplate.expire(lockKey, 30, TimeUnit.SECONDS);
// ========= setnx 竞争锁失败 ==========
if (!result) {
return "{code: 10001, message:请重新再试!}";
}
// ========== setnx 竞争锁成功 =======
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
// 相当于jedis.set(key, value)
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
} finally { // 防止异常导致锁无法释放!!!
// 成功扣减库存后的请求,需要释放这个lockKey
// 如果lockKey对应的value是本次请求设置的value,才允许释放锁!
// 下面这个代码也有问题!!!判断和删除不是原子的,并发场景可能存在问题:
// t1加锁成功,执行到get时候 ,判断equals为true,
// 刚好这个时候发生了expire,已经自动释放了锁。然后,t2加锁成功。
// t1 由于判断了equals, 执行del。实际上释放了t2加的锁
if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
stringRedisTemplate.delete(lockKey);
}
}
return "end";
}
使用Redis的setnx来实现分布式锁的话,这样的解决方案是可行的,一些公司也有这样使用分布式锁的!
存在的的问题:这样虽然解决了不同请求释放锁的问题,但是依然可能导致bug. 如果第一个请求要执行15s, 而超过了10s的过期时间,导致锁被自动释放,其他的请求就会进入扣减库存的代码。如果第一个请求恰好扣减完库存,还没来得及将结果写入到Redis中的时候,新的请求查询了库存。这样可能出现库存拆卖的问题。所以,这个过期时间设置为多少,需要我们自己权衡好。
那么,还有没有更好的解决方案呢?
现在存在的问题的原因是我们不太能确定下起来,这个过期时间到底设置为多少比较合适!
设置的太长,如果服务宕机没有在finally块中释放锁的话,这样就需要等待很久的时间才能释放锁。
设置的太短,可能会因为第一个请求时间异常导致锁被提前释放,而扣减库存的业务还没执行完,从而导致超卖问题!
归根结底,是这超时时间的设置问题!
在当前认知中,似乎已经没有更好的解决方案了。我们需要打破认知,引入新的概念了:font color=“red”> 锁续命/font>。
锁续命(也称看门狗)
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);
假如我们现在设置锁的过期时间是30s,我们可以再后台启动一个子线程去执行一个定时器,每过1 / 3的过期时间后(30 / 3 = 10 s)就去检查一下当前的锁状态:
如果锁还没有被释放(说明依然在执行扣减库存的业务代码),那么我们就重新给这个请求设置锁的过期时间为30s
。从而让这个请求可以持续的持有锁。
如果发现锁已经被释放了,那么就直接结束这个子线程。
这个锁续命的想法非常之巧妙,但是在高并发的场景下让我们自己来实现,势必不是那么容易。
这个一个简单的分布式锁,我们就踩了很多坑,如果没有高并发经验的人来写,那后果更不可想象。
所以,市面上现在已经存在一些技术来帮助我们解决Redis分布式锁的问题了。
我们用的比较多的是Redisson. 下面我们来学习一下Redeisson.
2、使用Redisson实现分布式锁
依赖:
dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.6.5</version>
</dependency>
准备工作做好之后,我们就来开始使用Redisson实现分布式锁吧
package com.jihu.redis.lock;
import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class StockForRedissonController {
@Autowired
private Redisson redisson;
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 模拟减库存
* @return ""
*/
@RequestMapping("/deduct_stock")
public String deductStock() {
String lockKey = "lockKey";
// 获取到redisson锁对象
RLock redissonLock = redisson.getLock(lockKey);
try {
// ========= 添加redisson锁并实现锁续命功能 =============
/**
* 主要执行一下几个操作
*
* 1、将localKey设置到Redis服务器上,默认过期时间是30s
* 2、每10s触发一次锁续命功能
*/
redissonLock.lock();
// ======== 扣减库存业务员开始 ============
// 从redis获取库存数量
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 如果库存数量大于0
if (stock > 0) {
int realStock = stock -1;
// 相当于jedis.set(key, value)
stringRedisTemplate.opsForValue().set("stock", realStock + "");
System.out.println("扣减成功,剩余库存:" + realStock + "");
} else { // 如果库存数量小于0
System.out.println("扣减失败,库存不足!");
}
// ======== 扣减库存业务员结束 ============
} finally { // 防止异常导致锁无法释放!!!
// ============= 释放redisson锁 ==========
redissonLock.unlock();
}
return "end";
}
}
就这!!!!!????
就这么几行代码就搞定了分布式锁?
不得不说,这个Redisson有点东西呀。我们自己及使用setnx的时候要考虑各种情况,而且稍不注意,就会出错。