高并发核心技术 - 订单与库存

最新推荐文章于 2024-05-27 17:26:01 发布

XingXing_Java

最新推荐文章于 2024-05-27 17:26:01 发布

阅读量1.9k

点赞数 5

分类专栏： Java Redis p6 阿里巴巴美团百度面试高可用高并发订单 Java工程师面试题文章标签： Java 高并发 Redis 订单库存

本文链接：https://blog.csdn.net/XingXing_Java/article/details/95055444

版权

在高并发环境中确保订单与库存安全是关键。本文探讨了不同预占库存方案，如加入购物车、下单时和支付时预占，最终推荐在下单时预占以平衡用户体验和库存安全。同时，针对重复下单问题提出了解决方案，如UI限制、下单唯一token和数据库乐观锁。在库存减扣方面，介绍了不安全、乐观锁、Redis分布式锁和Redis原子操作等多种方法，权衡并发性能和安全性。最后，讨论了订单时效性和取消后的库存回滚策略。

摘要由CSDN通过智能技术生成

点关注，不迷路；持续更新Java相关技术及资讯！！！

在这里插入图片描述
问题：

一件商品只有100个库存，现在有1000或者更多的用户来购买，每个用户计划同时购买1个到几个不等商品。如何保证库存在高并发的场景下是安全的。
1.不多发
2.不少发

下单涉及的一些步骤

1.下单
2.下单同时预占库存
3.支付
4.支付成功真正减扣库存
5.取消订单
6.回退预占库存

什么时候进行预占库存

方案一：加入购物车的时候去预占库存。
方案二：下单的时候去预占库存。
方案三：支付的时候去预占库存。

分析：

方案一：加入购物车并不代表用户一定会购买,如果这个时候开始预占库存，会导致想购买的无法加入购物车。而不想购买的人一直占用库存。显然这种做法是不可取的。

方案二：商品加入购物车后，选择下单，这个时候去预占库存。用户选择去支付说明了，用户购买欲望是比方案一要强烈的。订单也有一个时效，例如半个小时。超过半个小时后，系统自动取消订单，回退预占库存。

方案三：下单成功去支付的时候去预占库存。只有100个用户能支付成功，900个用户支付失败。用户体验不好，就像你走了一条光明大道，一路通畅，突然被告知此处不通行。而且支付流程也是一个比较复杂的流程，如果和减库存放在一起，将会变的更复杂。
所以综上所述：
选择方案二比较合理。

重复下单问题

用户点击过快，重复提交两次。
网络延时，用户刷新或者点击下单重复提交。
网络框架重复请求，某些网络框架，在延时比较高的情况下会自动重复请求。
用户恶意行为。

解决办法

在UI拦截，点击后按钮置灰，不能继续点击，防止用户，连续点击造成的重复下单。
在下单前获取一个下单的唯一token，下单的时候需要这个token。后台系统校验这个 token是否有效，才继续进行下单操作。

/**
     * 先生成 token 保存到 Redis
     * token 作为 key , 并设置过期时间 时间长度 根据任务需求
     * value 为数字 自增判断 是否使用过
     *
     * @param user
     * @return
     */
public String createToken(User user) {
   
	String key = "placeOrder:token:" + user.getId();
	String token = UUID.randomUUID().toString();
	//保存到Redis
	redisService.set(key + token, 0, 1000L);
	return token;
}
/**
     * 校验下单的token是否有效
     * @param user
     * @param token
     * @return
     */
public Boolean checkToken(User user, String token) {
   
	String key = "placeOrder:token:" + user.getId();
	if (null != redisService.get(key + token)) {
   
		long times = redisService.increment(key + token, 1);
		if (times == 1) {
   
			//利用increment 原子性 判断是否 该token 是否使用
			return true;
		} else<