扫码关注官方微信

扫码下载APP
返回顶部
首页 > 资讯 > 后端开发 > Python >Springboot整合Redis实现超卖问题还原和流程分析(分布式锁)
  • 874

0
分享到

Springboot整合Redis实现超卖问题还原和流程分析(分布式锁)

2024-04-02 19:04:59 874人浏览 泡泡鱼

Python 官方文档：入门教程 => 点击学习

摘要

目录超卖简单代码超卖问题单服务器单应用情况下设置synchronizedRedis实现分布式锁 通过超时间解决上述问题通过key设置值匹配的方式解决形同虚设问题 

超卖简单代码

写一段简单正常的超卖逻辑代码，多个用户同时操作同一段数据，探究出现的问题。

Redis中存储一项数据信息，请求对应接口，获取商品数量信息；
商品数量信息如果大于0，则扣减1，重新存储Redis中；
运行代码测试问题。



@RestController
public class RedisController {
	
	// 引入String类型redis操作模板
	@Autowired
	private StringRedisTemplate stringRedisTemplate;
 
 
	// 测试数据设置接口
	@RequestMapping("/setStock")
	public String setStock() {
		stringRedisTemplate.opsForValue().set("stock", "100");
		return "ok";
	}
	
	// 模拟商品超卖代码
	@RequestMapping("/deductStock")
	public String deductStock() {
		// 获取Redis数据库中的商品数量
		Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
		// 减库存
		if(stock > 0) {
			int realStock = stock -1;
			stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
			System.out.println("商品扣减成功，剩余商品："+realStock);
		}else {
			System.out.println("库存不足.....");
		}
		return "end";
	}
}

超卖问题

单服务器单应用情况下

在单应用模式下，使用jmeter压测。

 测试结果：

每个请求相当于一个线程，当几个线程同时拿到数据时，线程A拿到库存为84，这个时候线程B也进入程序，并且抢占了CPU，访问库存为84，最后两个线程都对库存减一，导致最后修改为83，实际上多卖出去了一件

既然线程和线程之间，数据处理不一致，能否使用synchronized加锁测试？

设置synchronized

依旧还是先测试单服务器


    // 模拟商品超卖代码,
	// 设置synchronized同步锁
	@RequestMapping("/deductStock1")
	public String deductStock1() {
		synchronized (this) {
			// 获取Redis数据库中的商品数量
			Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
			// 减库存
			if(stock > 0) {
				int realStock = stock -1;
				stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
				System.out.println("商品扣减成功，剩余商品："+realStock);
			}else {
				System.out.println("库存不足.....");
			}
		}
		return "end";
	}

数量100

重新压测，得到的日志信息如下所示： 

 在单机模式下，添加synchronized关键字，的确能够避免商品的超卖现象！

但是在分布式微服务中，针对该服务设置了集群，synchronized依旧还能保证数据的正确性吗？

假设多个请求，被注册中心负载均衡，每个微服务中的该处理接口，都添加有synchronized，

 依然会出现类似的超卖问题：

synchronized只是针对单一服务器的JVM进行加锁，但是分布式是很多个不同的服务器，导致两个线程或多个在不同服务器上共同对商品数量信息做了操作！

Redis实现分布式锁 

在Redis中存在一条命令setnx (set if not exists)

setnx key value
如果不存在key，则可以设置成功；否则设置失败。

修改处理接口，增加key


// 模拟商品超卖代码
	@RequestMapping("/deductStock2")
	public String deductStock2() {
		// 创建一个key，保存至redis
		String key = "lock";
		// setnx
		// 由于redis是一个单线程，执行命令采取“队列”形式排队！
		// 优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败。
		boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
		// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
		if (!result) {
			// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
			return "err";
		}
		
		// 获取Redis数据库中的商品数量
		Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
		// 减库存
		if(stock > 0) {
			int realStock = stock -1;
			stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
			System.out.println("商品扣减成功，剩余商品："+realStock);
		}else {
			System.out.println("库存不足.....");
		}
 
        // 程序执行完成，则删除这个key
		stringRedisTemplate.delete(key);
 
		return "end";
	}

1、请求进入接口中，如果redis中不存在key，则会新建一个setnx；如果存在，则不会新建，同时返回错误编码，不会继续执行抢购逻辑。
2、当创建成功后，执行抢购逻辑。
3、抢购逻辑执行完成后，删除数据库中对应的setnx的key。让其他请求能够设置并操作。

这种逻辑来说比之前单一使用syn合理的多，但是如果执行抢购操作中出现了异常，导致这个key无法被删除。以至于其他处理请求，一直无法拿到key，程序逻辑死锁！

可以采取try … finally进行操作 



	@RequestMapping("/deductStock3")
	public String deductStock3() {
		// 创建一个key，保存至redis
		String key = "lock";
		// setnx
		// 由于redis是一个单线程，执行命令采取队列形式排队！优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败
		boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
		// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
		if (!result) {
			// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
			return "err";
		}
 
		try {
			// 获取Redis数据库中的商品数量
			Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
			// 减库存
			if (stock > 0) {
				int realStock = stock - 1;
				stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
				System.out.println("商品扣减成功，剩余商品：" + realStock);
			} else {
				System.out.println("库存不足.....");
			}
		} finally {
			// 程序执行完成，则删除这个key
			// 放置于finally中，保证即使上述逻辑出问题，也能del掉
			stringRedisTemplate.delete(key);
		}
 
		return "end";
	}

这个逻辑相比上面其他的逻辑来说，显得更加的严谨。

但是，如果一套服务器，因为断电、系统崩溃等原因出现宕机，导致本该执行finally中的语句未成功执行完成！！同样出现key一直存在，导致死锁！

通过超时间解决上述问题

在设置成功setnx后，以及抢购代码逻辑执行前，增加key的限时。



	@RequestMapping("/deductStock4")
	public String deductStock4() {
		// 创建一个key，保存至redis
		String key = "lock";
		// setnx
		// 由于redis是一个单线程，执行命令采取队列形式排队！优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败
		//boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
 
		//让设置key和设置key的有效时间都可以同时执行
		boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock", 10, TimeUnit.SECONDS);
 
		// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
		if (!result) {
			// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
			return "err";
		}
		// 设置key有效时间
		//stringRedisTemplate.expire(key, 10, TimeUnit.SECONDS);
 
		try {
			// 获取Redis数据库中的商品数量
			Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
			// 减库存
			if (stock > 0) {
				int realStock = stock - 1;
				stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
				System.out.println("商品扣减成功，剩余商品：" + realStock);
			} else {
				System.out.println("库存不足.....");
			}
		} finally {
			// 程序执行完成，则删除这个key
			// 放置于finally中，保证即使上述逻辑出问题，也能del掉
			stringRedisTemplate.delete(key);
		}
 
		return "end";
	}

但是上述代码的逻辑中依旧会有问题：

如果处理逻辑中，出现超时问题。
当逻辑执行时，时间超过设定key有效时间，此时会出现什么问题？

 从上图可以清楚的发现问题：
如果一个请求执行时间超过了key的有效时间。
新的请求执行过来时，必然可以拿到key并设置时间；
此时的redis中保存的key并不是请求1的key，而是别的请求设置的。
当请求1执行完成后，此处删除key，删除的是别的请求设置的key！

依然出现了key形同虚设的问题！如果失效一直存在，超卖问题依旧不会解决。

通过key设置值匹配的方式解决形同虚设问题 

既然出现key形同虚设的现象，是否可以增加条件，当finally中需要执行删除操作时，获取数据判断值是否是该请求中对应的，如果是则删除，不是则不管！

修改上述代码如下所示：



	@RequestMapping("/deductStock5")
	public String deductStock5() {
		// 创建一个key，保存至redis
		String key = "lock";
		String lock_value = UUID.randomUUID().toString();
		// setnx
		//让设置key和设置key的有效时间都可以同时执行
		boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, lock_value, 10, TimeUnit.SECONDS);
		// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
		if (!result) {
			// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
			return "err";
		}
		try {
			// 获取Redis数据库中的商品数量
			Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
			// 减库存
			if (stock > 0) {
				int realStock = stock - 1;
				stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
				System.out.println("商品扣减成功，剩余商品：" + realStock);
			} else {
				System.out.println("库存不足.....");
			}
		} finally {
			// 程序执行完成，则删除这个key
			// 放置于finally中，保证即使上述逻辑出问题，也能del掉
 
			// 判断redis中该数据是否是这个接口处理时的设置的，如果是则删除
			if(lock_value.equalsIgnoreCase(stringRedisTemplate.opsForValue().get(key))) {
				stringRedisTemplate.delete(key);
			}
		}
		return "end";
	}

由于获得锁的线程必须执行完减库存逻辑才能释放锁，所以在此期间所有其他的线程都会由于没获得锁，而直接结束程序，导致有很多库存根本没有卖出去，所以这里应该可以优化，让没获得锁的线程等待，或者循环检查锁 

最终版

我们将锁封装到一个实体类中，然后加入两个方法，加锁和解锁


@Component
public class RedisLock {
    private final Logger log = LoggerFactory.getLogger(this.getClass());
 
    private final long acquireTimeout = 10*1000;    // 获取锁之前的超时时间(获取锁的等待重试时间)
    private final int timeOut = 20;   // 获取锁之后的超时时间(防止死锁)
 
    @Autowired
    private StringRedisTemplate stringRedisTemplate;  // 引入String类型redis操作模板
 
    
    public boolean getRedisLock(String lockName,String lockValue) {
        // 1.计算获取锁的时间
        Long endTime = System.currentTimeMillis() + acquireTimeout;
        // 2.尝试获取锁
        while (System.currentTimeMillis() < endTime) {
            //3. 获取锁成功就设置过期时间 让设置key和设置key的有效时间都可以同时执行
            boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockName, lockValue, timeOut, TimeUnit.SECONDS);
            if (result) {
                return true;
            }
        }
        return false;
    }
 
 
    
    public void unRedisLock(String lockName,String lockValue) {
        if(lockValue.equalsIgnoreCase(stringRedisTemplate.opsForValue().get(lockName))) {
            stringRedisTemplate.delete(lockName);
        }
    }
}

@RestController
public class RedisController {
	
	// 引入String类型redis操作模板
	@Autowired
	private StringRedisTemplate stringRedisTemplate;
	@Autowired
	private RedisLock redisLock;
 
 
	@RequestMapping("/setStock")
	public String setStock() {
		stringRedisTemplate.opsForValue().set("stock", "100");
		return "ok";
	}
 
	@RequestMapping("/deductStock")
	public String deductStock() {
		// 创建一个key，保存至redis
		String key = "lock";
		String lock_value = UUID.randomUUID().toString();
		try {
			boolean redisLock = this.redisLock.getRedisLock(key, lock_value);//获取锁
			if (redisLock)
			{
				// 获取Redis数据库中的商品数量
				Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
				// 减库存
				if (stock > 0) {
					int realStock = stock - 1;
					stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
					System.out.println("商品扣减成功，剩余商品：" + realStock);
				} else {
					System.out.println("库存不足.....");
				}
			}
		} finally {
			redisLock.unRedisLock(key,lock_value);   //释放锁
		}
		return "end";
	}
}

可以看到失败的线程不会直接结束，而是会尝试重试，一直到重试结束时间，才会结束

实际上这个最终版依然存在3个问题

1、在finally流程中，由于是先判断在处理。如果判断条件结束后，获取到的结果为true。但是在执行del操作前，此时jvm在执行GC操作(为了保证GC操作获取GC roots根完全，会暂停java程序)，导致程序暂停。GC操作执行完成后(暂停恢复后)，执行del操作，但是此时的key还在当前加锁的key么？

2、问题如图所示

到此这篇关于SpringBoot整合Redis实现超卖问题还原和分析的文章就介绍到这了,更多相关springboot整合Redis内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！

您可能感兴趣的文档:

--结束END--

本文标题: Springboot整合Redis实现超卖问题还原和流程分析(分布式锁)

本文链接: https://lsjlt.com/news/155093.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • Springboot整合Redis实现超卖问题还原和流程分析(分布式锁)
    目录超卖简单代码超卖问题单服务器单应用情况下设置synchronizedRedis实现分布式锁 通过超时间解决上述问题通过key设置值匹配的方式解决形同虚设问题 ...
    99+
    2024-04-02
  • Redis分布式锁解决秒杀超卖问题
    目录分布式锁应用场景单体锁的分类分布式锁核心逻辑分布式锁实现的问题——死锁和解决Redis解决删除别人锁的问题分布式锁应用场景 秒杀环境下：订单服务从库存中心拿到库存数，如果库存总数大于0，则进...
    99+
    2022-07-13
    Redis秒杀超卖 Redis分布式锁
  • SpringBoot整合Redisson实现分布式锁
    目录一、添加依赖二、redis配置文件三、新建配置类四、使用分布式锁可重入锁读写锁信号量（Semaphore）闭锁（CountDownLatch）Redisson是架设在redis基...
    99+
    2024-04-02
  • springboot整合curator实现分布式锁过程
    目录springboot curator实现分布式锁理论篇：实操篇：项目实际应用中分布式锁介绍锁的介绍悲观锁-数据库锁悲观锁-缓存锁分布式锁—zookeepersprin...
    99+
    2024-04-02
  • SpringBoot整合Redisson如何实现分布式锁
    这篇文章将为大家详细讲解有关SpringBoot整合Redisson如何实现分布式锁，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。Redisson是架设在redis基础上的一个Java驻内存数据网格（In...
    99+
    2023-06-25
  • redis分布式锁的实现原理实例分析
    这篇文章主要介绍了redis分布式锁的实现原理实例分析的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇redis分布式锁的实现原理实例分析文章都会有所收获，下面我们一起来看看吧。首先，为了确保分布式锁可用，我们至...
    99+
    2023-06-29
  • Spring Boot整合Zookeeper实现分布式锁的场景分析
    目录一、Java当中关于锁的概念1.1.什么是锁1.2.锁的使用场景1.3.什么是分布式锁1.4.分布式锁的使用场景二、zk实现分布式锁2.1.zk中锁的种类：2.2.zk如何上读锁...
    99+
    2024-04-02
  • SpringBoot基于Redis的分布式锁实现过程记录
    目录一、概述二、环境搭建三、模拟一个库存扣减的场景四、总结一、概述 什么是分布式锁 在单机环境中，一般在多并发多线程场景下，出现多个线程去抢占一个资源，这个时候会出现线程同步问题，造...
    99+
    2024-04-02
  • springboot整合shardingsphere和seata实现分布式事务的实践
    各个框架版本信息 springboot: 2.1.3springcloud: Greenwich.RELEASEseata: 1.0.0shardingsphere:4.0.1 ma...
    99+
    2024-04-02
  • 如何分析springboot响应式编程整合webFlux的问题
    这期内容当中小编将会给大家带来有关如何分析springboot响应式编程整合webFlux的问题，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。在servlet3.0标准之前，是每一个请求对应一个线程。如果...
    99+
    2023-06-29
  • Redis分布式锁的原理是什么和怎么实现
    这篇文章主要介绍了Redis分布式锁的原理是什么和怎么实现的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇Redis分布式锁的原理是什么和怎么实现文章都会有所收获，下面我们一起来看看吧。1 一人一单并发安全问题之...
    99+
    2023-07-04
  • Springboot基于Redisson实现Redis分布式可重入锁源码解析
    目录一、前言二、为什么使用Redisson1. 我们打开官网2. 我们可以看到官方让我们去使用其他3. 打开官方推荐4. 找到文档三、Springboot整合Redisson1. 导...
    99+
    2024-04-02
  • springboot整合xxl-job实现分布式定时任务的过程
    目录一、前言二、xxl-job介绍三、修改配置1. 运行sql文件2. 修改xxl-job-admin配置3. 需修改xxl-job-executor-sample-springbo...
    99+
    2022-11-13
    springboot整合xxl-job定时任务 springboot整合xxl-job springboot定时任务
  • Springboot基于Redisson如何实现Redis分布式可重入锁源码解析
    这篇文章主要介绍了Springboot基于Redisson如何实现Redis分布式可重入锁源码解析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。一、前言我们在实现使用Redi...
    99+
    2023-06-29
软考高级职称资格查询
热门wiki
近期文章
推荐阅读
热门问答
热门标签
编程网，编程工程师的家园，是目前国内优秀的开源技术社区之一，形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容，为IT开发者提供了一个发现、使用、并交流开源技术的平台。

  • 官方手机版

  • 微信公众号

  • 商务合作