本文原文链接
文章很长,且持续更新,建议收藏起来,慢慢读!疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 :
免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ,帮你 实现技术自由,完成职业升级, 薪酬猛涨!加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程(卷1)加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程(卷2)加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程(卷3)加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 资源宝库: Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取
招行面试:亿级秒杀,超卖问题+少卖问题,如何解决?(图解+秒懂+史上最全)
尼恩特别说明: 尼恩的文章,都会在 《技术自由圈》 公号 发布, 并且维护最新版本。 如果发现图片 不可见, 请去 《技术自由圈》 公号 查找
尼恩说在前面
在45岁老架构师 尼恩的读者交流群(50+)中,最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团、蚂蚁、得物的面试资格,遇到很多很重要的相关面试题:
问题 :如何解决高并发下的库存抢购超卖少买?
问题 :亿级秒杀,如何解决超卖少买?
最近有小伙伴面试招行, 问到了相关的面试题。
小伙伴没有系统的去梳理和总结,所以支支吾吾的说了几句,面试官不满意,面试挂了。
所以,尼恩给大家做一下系统化、体系化的梳理,使得大家内力猛增,可以充分展示一下大家雄厚的 “技术肌肉”,让面试官爱到 “不能自已、口水直流”,然后实现”offer直提”。
当然,这道面试题,以及参考答案,也会收入咱们的 《尼恩Java面试宝典PDF》V175版本,供后面的小伙伴参考,提升大家的 3高 架构、设计、开发水平。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF,请到文末公号【技术自由圈】获取
招商银行的高阶Java后端面试真题
被狠狠拷打了,问的人都懵了。项目场景题太难了,不好好准备,真的答不出!
尼恩将给出全部答案:
1.如何让系统抗住双十一的预约抢购活动?
45岁资深老架构师尼恩的参考答案,点此查看
2.如何从零搭建10万级QPS大流量、高并发优惠券系统?
45岁资深老架构师尼恩的参考答案,点此查看
3.百万级别数据的 Excel 如何快速导入到数据
45岁资深老架构师尼恩的参考答案,点此查看
4.如何设计一个支持万亿GB网盘实现秒传与限速的系统?
45岁资深老架构师尼恩的参考答案,点此查看
5.如何根据应用场景选择合适的消息中间件?
45岁资深老架构师尼恩的参考答案,点此查看
6.如何提升 RocketMQ 顺序消费性能?
即将发布。
7.设计分布式调度框架,该考虑哪些问题?
45岁资深老架构师尼恩的参考答案,点此查看
9.如何让系统抗住双十一的预约抢购活动?
45岁资深老架构师尼恩的参考答案,点此查看
10.问 :如何解决高并发下的库存抢购超卖少买?
本文
11.为什么高并发下数据写入不推荐关系数据?
45岁资深老架构师尼恩的参考答案,点此查看
12.如果让你设计一个分布式链路跟踪系统?
即将发布。
前几天 尼恩给一个 小伙伴改造过一个 100wtps 链路跟踪平台简历, 非常NB, 牛到暴表。
本文目录
一:超卖少买问题描述
在电商系统中买商品过程,先加入购物车,然后选中商品,点击结算,即会进入待支付状态,后续支付。
一般电子商务网站都会遇到如团购、秒杀、特价之类的活动,而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。
场景一:买家需要购买数量可以多件
场景二:秒杀活动,到时间点只能购买一件
然而,作为活动商品,库存肯定是很有限的,如何控制库存不让出现超卖 ,以防止造成不必要的损失是众多电子商务网站程序员头疼的问题,这同时也是最基本的问题。
在秒杀系统设计中,超卖是一个经典、常见的问题,任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难点。
在多个用户同时发起对同一个商品的下单请求时,先查询商品库存,再修改商品库存,会出现资源竞争问题,导致库存的最终结果出现异常。
问题:
当商品A一共有库存15件,用户甲先下单10件,用户乙下单8件,这时候库存只能满足一个人下单成功,如果两个人同时提交,就出现了超卖的问题。
二:高并发秒杀下单 交互流程的 4个阶段
45岁老架构师,首先给大家梳理一下, 秒杀下单 的四个阶段:
-
第一阶段 扣库预扣,
-
第二阶段 库存扣减,
-
第三阶段支付回调,
-
第四阶段库存补偿,
图解:秒杀下单 4个阶段的流程图:
第一阶段 扣库预扣
用户选中秒杀商品点击“抢购”, 后端收到下单请求, 使用redis lua 脚本进行redis 库存的预扣 ,保障库存预扣的原子性,下一个用户看到库存量已经被减少1个,
扣减库存的操作,使用redis 分布式锁保障幂等性,防止 用户同一秒触发重复“抢购”,
下单请求,发送消息队列,进入第二阶段
第二阶段 库存扣减
使用redis 分布式锁 保障 订单操作的幂等性,防止 同一个请求重复下单,
使用本地消息表分布式事务,解决订单和库存的数据之间最终一致性方案
完成下单后,订单状态 变成了待支付
下单的主体流程,至此基本结束
第三阶段支付回调
后续在页面再触发支付流程,支持完成后会回调订单服务,修改订单状态
第四阶段库存补偿
使用延迟消息/定时任务,对超时未支付订单进行关闭,并且对库存进行补偿
三:异步模式下的两阶段 下单
下单的主体流程就是在第一阶段 扣库预扣,第二阶段 库存扣减 。
-
第一阶段 扣库预扣,申请成功之后,进入消息队列;
-
第二阶段 库存扣减 ,从消息队列消费 下单请求,然后完成下单操作。 查库存 -> 创建订单 -> 扣减库存。通过分布式锁 、分布式事务机制保障解决多个provider实例并发下单产生的超卖问题。
分为两个阶段后,属于经典的异步模式。
图解:分阶段排队架构图
第一阶段 扣库预扣 详解
用户选中秒杀商品点击“抢购”, 后端收到下单请求, 使用redis lua 脚本进行redis 库存的预扣 ,保障库存预扣的原子性。
这里,将存库扣减前移,从MySQL前移到Redis中,所有的预减库存的操作放到内存中。
扣减库存的操作,使用redis 分布式锁保障幂等性,防止 用户同一秒触发重复“抢购”。
由于Redis的写性能和读性能都远高于MySQL,这就解决了高并发下的性能问题,提升了并发量10倍以上。
下单请求,发送消息队列,进入第二阶段
第二阶段 库存扣减 详解
第二阶段 , 然后通过队列等异步手段,将变化的数据异步写入到DB中。‘
-
幂等性保证:使用redis 分布式锁 保障 订单操作的幂等性,防止 同一个请求重复下单,
-
一致性保证:使用本地消息表分布式事务,解决订单和库存的数据之间最终一致性方案
完成下单后,订单状态 变成了待支付
下单的主体流程,至此基本结束
四:两阶段 下单 方案3大缺点:
- 不一致的问题:
由于异步写入DB,可能存在数据不一致,存在某一时刻DB和Redis中数据不一致的风险。
- 少买 问题
可能存在少买,也就是如果拿到号的人不真正下订单,可能库存减为0,但是订单数并没有达到库存阀值,有效 订单少了。
- 超卖 问题
可能存在超卖 ,也就是 库存减为0, 订单数 超过了库存阀值,有效 订单多了。
五:如何解决超卖 问题
这里,将存库扣减前移,从MySQL前移到Redis中,所有的预减库存的操作放到内存中。
在第一阶段,用分布式锁,是为了防刷、防止同一个用户同一秒里面把购物车里的商品进行多次结算,防止前端代码出问题触发两次,就会解决超卖问题。
用户选中秒杀商品点击“抢购”, 后端收到下单请求, 进行redis 库存的预扣 。
扣减库存的操作,使用redis 分布式锁保障幂等性,防止 用户同一秒触发重复“抢购”,解决超卖问题。
以下是一个使用 Java 和 Redis 分布式锁解决秒杀超卖问题的示例代码。 示例代码如下:
import redis.clients.jedis.Jedis;public class SeckillDemo {private static final String LOCK_SUCCESS = "OK";private static final String SET_IF_NOT_EXIST = "NX";private static final String SET_WITH_EXPIRE_TIME = "PX";private static final int LOCK_EXPIRE_TIME = 1000; // 锁的过期时间,单位为毫秒public static void main(String[] args) {Jedis jedis = new Jedis("localhost", 6379);String productId = "123456"; // 商品IDString userId = "user123"; // 用户IDboolean result = seckill(jedis, productId, userId);if (result) {System.out.println("用户 " + userId + " 秒杀商品 " + productId + " 成功!");} else {System.out.println("用户 " + userId + " 秒杀商品 " + productId + " 失败!");}jedis.close();}public static boolean seckill(Jedis jedis, String productId, String userId) {String lockKey = "seckill_lock:" + productId;String stockKey = "seckill_stock:" + productId;String uniqueValue = System.currentTimeMillis() + userId; // 唯一值,用于防止误删锁// 尝试获取锁String result = jedis.set(lockKey, uniqueValue, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, LOCK_EXPIRE_TIME);if (LOCK_SUCCESS.equals(result)) {try {// 获取商品库存String stockStr = jedis.get(stockKey);int stock = stockStr == null? 0 : Integer.parseInt(stockStr);if (stock > 0) {// 扣减库存jedis.decr(stockKey);System.out.println("库存扣减成功,当前库存: " + (stock - 1));return true;} else {System.out.println("库存不足,秒杀失败");return false;}} finally {// 释放锁,使用 Lua 脚本来确保原子性String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";jedis.eval(script, 1, lockKey, uniqueValue);}} else {System.out.println("获取锁失败,正在排队或秒杀已结束");return false;}}
}
5.1 解决超卖 的代码解释:
首先,根据商品 ID 生成一个唯一的锁键 lockKey
和库存键 stockKey
。
第二步,抢锁。 尝试使用 jedis.set
方法获取锁,该方法的参数包括锁键、唯一值、NX
和 PX
以及锁的过期时间。
如果抢锁成功(返回 OK
),进入秒杀逻辑。
第三步,预扣库存。 获取商品库存,若库存大于 0,则使用 jedis.decr
方法扣减库存,同时打印当前库存。
第四步,释放锁。 无论秒杀成功与否,最终都要释放锁。这里 使用 Lua 脚本来释放锁,确保只有加锁的客户端才能释放锁,避免误删锁的情况。Lua 脚本首先检查锁的值是否与之前存储的唯一值相等,如果相等,则删除锁,否则不做任何操作。
5.2 解决超卖 的代码流程图:
5.3 使用分布式锁要解决的问题
分布式锁要解决的问题很多,比如下面的三个大问题:
- 锁失效的问题
- 锁的自动续期问题
- Redis分段锁问题
- 其他的高可用、高并发问题?
第一 解决 锁的自动续期:
在复杂的业务逻辑中,可能需要使用 watchdog
机制,通过定时任务在锁即将过期时对锁进行续期,防止业务逻辑还未完成而锁过期。
具体请参见 45岁老架构师尼恩的深度文章:史上最全: Redis锁如何续期 ?Redis锁超时,任务没完怎么办?
第二 解决 锁失效的问题:
master Redis实例挂掉了,slave 从Redis 还没有完成复制,导致 Redis分布式锁失效,怎么办?
具体请参见 45岁老架构师尼恩的深度文章: 史上最全:Redis分布式 锁失效了,怎么办?
第三 解决 锁分段的问题:
master Redis实例挂掉了,slave 从Redis 还没有完成复制,导致 Redis分布式锁失效,怎么办?
具体请参见 45岁老架构师尼恩的深度文章: 史上最全:Redis分段锁,如何设计?
第四 解决 其他的高可用、高并发问题? 具体请参见 45岁老架构师尼恩的深度文章:
史上最全: Redis: 缓存击穿、缓存穿透、缓存雪崩 ,如何彻底解决?
史上最全:Redis脑裂 ,如何预防?
史上最全:Redis分段锁,如何设计?
redis 锁的5个大坑,如何规避?
史上最全:Redis热点Key,如何 彻底解决问题
史上最全:如何保持 Redis 数据一致性?
六:如何解决少卖 问题?
在秒杀场景中,可能会出现少卖问题,即实际卖出的商品数量少于实际库存。
如果要解决少卖,方便后面的人下单, 需要恢复库存数量。
恢复库存数量,有很多方案可以解决:
1 使用RocketMQ 延迟消息
2 使用xxl-job 的定时任务
6.1. 使用RocketMQ 延迟消息解决少卖 问题?
通过使用延迟消息,可以在订单提交后设置一个延迟时间,让系统在延迟时间后再次检查订单状态,确保库存正确扣减。
RocketMQ默认支持18个延时级别,分别为:
1s, 5s, 10s, 30s, 1m, 2m, 3m, 4m, 5m, 6m, 7m, 8m, 9m, 10m, 20m, 30m, 1h, 2h
如果需要更多的延时级别,可以在broker.conf
文件中进行配置。
例如,增加2天的延时级别:
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h 2d
在用户提交订单后,生产者发送一条延迟消息到RocketMQ 去做 订单的检查,库存补偿。
假设我们希望在订单提交后10m 检查订单状态,可以设置延迟级别为14(10分钟)。
生产者发送延迟消息的代码
import org.apache.rocketmq.client.producer.DefaultMQProducer;
import org.apache.rocketmq.client.producer.SendResult;
import org.apache.rocketmq.common.message.Message;public class ProducerDelay {public static void main(String[] args) throws Exception {DefaultMQProducer producer = new DefaultMQProducer("producerGroup");producer.setNamesrvAddr("localhost:9876");producer.start();Message msg = new Message("SECKILL_CHECK_TOPIC", "订单001".getBytes());msg.setDelayTimeLevel(14); // 设置延迟10分钟SendResult sendResult = producer.send(msg);System.out.println("发送结果: " + sendResult);producer.shutdown();}
}
消费者处理延迟消息
消费者在10分钟后接收到延迟消息,检查订单状态。
如果订单未支付,可以进行相应的处理,如取消订单、释放库存等。
import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyListener;
import org.apache.rocketmq.common.message.MessageExt;public class ConsumerDelay {public static void main(String[] args) throws Exception {DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumerGroup");consumer.setNamesrvAddr("localhost:9876");consumer.subscribe("SECKILL_TOPIC", "*");consumer.registerMessageListener(new ConsumeConcurrentlyListener() {@Overridepublic ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {for (MessageExt msg : msgs) {System.out.println("接收到延迟消息: " + new String(msg.getBody()));// 检查订单状态String orderId = new String(msg.getBody());if (isOrderUnpaid(orderId)) {// 订单未支付,取消订单,释放库存cancelOrder(orderId);}}return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;}});consumer.start();System.out.println("消费者启动成功");}private static boolean isOrderUnpaid(String orderId) {// 模拟检查订单状态return true; // 假设订单未支付}private static void cancelOrder(String orderId) {// 模拟取消订单,释放库存// DB中的库存 +1// Redis 中的库存 +1System.out.println("取消订单: " + orderId);}
}
以上步骤,使用RocketMQ的延迟消息可以有效解决秒杀场景中的少卖问题,确保订单处理的准确性和及时性。
6.2. 使用 xxl-job 定时任务解决少卖 问题?
使用xxl-job 定时任务,进行未支付订单的检查,库存补偿。
一般来说,订单信息存储在数据库中,包含订单状态(如已支付、未支付、已取消等)、订单创建时间、商品信息等。
当用户下单后,订单初始状态为未支付,并记录订单创建时间。
xxl-job 定时任务执行逻辑
- 定时任务周期性地检查未支付订单,将超时的未支付订单标记为已取消。
- 对于已取消的订单,将其占用的库存进行补偿,恢复库存数量。
xxl-job 定时任务代码:
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Component;@Component
public class OrderTimeoutJobHandler {@Autowiredprivate JdbcTemplate jdbcTemplate;// 订单超时时间,单位为秒,例如 600 秒即 10分钟private static final int ORDER_TIMEOUT_SECONDS = 600;public void handleOrderTimeout() {// 计算超时时间long timeoutTimestamp = System.currentTimeMillis() - (ORDER_TIMEOUT_SECONDS * 1000);// 查询超时未支付订单String sql = "SELECT order_id, product_id, quantity FROM orders WHERE status = 'UNPAID' AND create_time < FROM_UNIXTIME(?)";List<Map<String, Object>> timeoutOrders = jdbcTemplate.queryForList(sql, timeoutTimestamp / 1000);for (Map<String, Object> order : timeoutOrders) {String orderId = (String) order.get("order_id");String productId = (String) order.get("product_id");int quantity = (int) order.get("quantity");// 取消订单cancelOrder(orderId);// 补偿库存compensateStock(productId, quantity);}}private void cancelOrder(String orderId) {String sql = "UPDATE orders SET status = 'CANCELLED' WHERE order_id =?";jdbcTemplate.update(sql, orderId);}private void compensateStock(String productId, int quantity) {//恢复 DB中的库存String sql = "UPDATE product_stock SET stock = stock +? WHERE product_id =?";jdbcTemplate.update(sql, quantity, productId);//恢复 redis 中的库存}
}
handleOrderTimeout 方法:
- 该方法由 xxl-job 定时触发,首先计算超时时间戳。
- 然后查询订单表中状态为
UNPAID
且创建时间早于超时时间戳的订单。 - 对于这些超时未支付订单,将其状态更新为
CANCELLED
,并对相应的商品库存进行补偿。
xxl-job 配置:
在 xxl-job-admin
管理界面中,添加一个定时任务,设置任务的调度规则,例如每 5 分钟执行一次,根据实际业务需求调整。
将 OrderTimeoutJobHandler
类注册到 xxl-job 中,并将 handleOrderTimeout
方法作为任务的执行方法。
xxl-job 定时任务解决少卖的注意事项:
- 调度周期的问题:
根据业务需求调整定时任务的调度周期,避免过于频繁或过于稀疏。
- 数据一致性问题:
在实际应用中,对于订单的创建、库存扣减、订单取消和库存补偿,可能需要使用数据库事务保证数据一致性,避免出现数据不一致的情况。
- 数据库索引的性能问题:
可以添加索引,提高查询效率,例如在订单表的 status
和 create_time
列上添加联合索引。
总之:
通过 xxl-job 定时任务, 可以定期检查未支付订单并进行库存补偿,确保业务的正常运行和库存的合理管理。
尼恩架构团队 塔尖 redis 面试题
京东面试: 亿级 数据黑名单 ,如何实现?(此文介绍了布隆过滤器、布谷鸟过滤器)
希音面试:亿级用户 日活 月活,如何统计?(史上最强 HyperLogLog 解读)
史上最全: Redis: 缓存击穿、缓存穿透、缓存雪崩 ,如何彻底解决?
史上最全:Redis脑裂 ,如何预防?
史上最全: Redis锁如何续期 ?Redis锁超时,任务没完怎么办?
史上最全:Redis分布式 锁失效了,怎么办?
史上最全:Redis分段锁,如何设计?
史上最全: redis 锁的5个大坑,如何规避?
史上最全:Redis热点Key,如何 彻底解决问题
史上最全:为啥Redis用哈希槽,不用一致性哈希?
史上最全:Redis分段锁,如何设计?
史上最全: redis 锁的5个大坑,如何规避?
史上最全:Redis热点Key,如何 彻底解决问题
史上最全:为啥Redis用哈希槽,不用一致性哈希?
史上最全:如何保持 Redis 数据一致性?
说在最后:有问题找老架构取经
只要按照上面的 尼恩团队梳理的 方案去作答, 你的答案不是 100分,而是 120分。 面试官一定是 心满意足, 五体投地。
按照尼恩的梳理,进行 深度回答,可以充分展示一下大家雄厚的 “技术肌肉”,让面试官爱到 “不能自已、口水直流”,然后实现”offer直提”。
在面试之前,建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》,里边有大量的大厂真题、面试难题、架构难题。
很多小伙伴刷完后, 吊打面试官, 大厂横着走。
技术自由的实现路径:
实现你的 架构自由:
《吃透8图1模板,人人可以做架构》
《10Wqps评论中台,如何架构?B站是这么做的!!!》
《阿里二面:千万级、亿级数据,如何性能优化? 教科书级 答案来了》
《峰值21WQps、亿级DAU,小游戏《羊了个羊》是怎么架构的?》
《100亿级订单怎么调度,来一个大厂的极品方案》
《2个大厂 100亿级 超大流量 红包 架构方案》
… 更多架构文章,正在添加中
实现你的 响应式 自由:
《响应式圣经:10W字,实现Spring响应式编程自由》
这是老版本 《Flux、Mono、Reactor 实战(史上最全)》
实现你的 spring cloud 自由:
《Spring cloud Alibaba 学习圣经》 PDF
《分库分表 Sharding-JDBC 底层原理、核心实战(史上最全)》
《一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系(史上最全)》
实现你的 linux 自由:
《Linux命令大全:2W多字,一次实现Linux自由》
实现你的 网络 自由:
《TCP协议详解 (史上最全)》
《网络三张表:ARP表, MAC表, 路由表,实现你的网络自由!!》
实现你的 分布式锁 自由:
《Redis分布式锁(图解 - 秒懂 - 史上最全)》
《Zookeeper 分布式锁 - 图解 - 秒懂》
实现你的 王者组件 自由:
《队列之王: Disruptor 原理、架构、源码 一文穿透》
《缓存之王:Caffeine 源码、架构、原理(史上最全,10W字 超级长文)》
《缓存之王:Caffeine 的使用(史上最全)》
《Java Agent 探针、字节码增强 ByteBuddy(史上最全)》
实现你的 面试题 自由:
4800页《尼恩Java面试宝典 》 40个专题
免费获取11个技术圣经PDF:
在刷题过程中,如果有啥问题,大家可以来 找 40岁老架构师尼恩交流。
另外,如果没有面试机会, 可以找尼恩来改简历、做帮扶。前段时间,刚指导一个小伙 暴涨200%(涨2倍),29岁/7年/双非一本 , 从13K一次涨到 37K ,逆天改命。
狠狠卷,实现 “offer自由” 很容易的, 前段时间一个武汉的跟着尼恩卷了2年的小伙伴, 在极度严寒/痛苦被裁的环境下, offer拿到手软, 实现真正的 “offer自由” 。