校验库存

这个就是检查商品库存有没有货，没有就直接返回，有就进入购买流程。我们发现检查库存走的是数据库，如下：

这个小伙伴们是不是发现有问题了，这么大量的请求过来，走数据库肯定是不行的，想到的肯定是把库存放到缓存中，因为是分布式，所以放到Redis中。

那就有个问题了，什么时候把商品库存放到缓存中？

最好的方式就是通过后台管理系统，因为我们新建一个秒杀商品，肯定是通过后台管理系统操作的，添加秒杀商品后，应该会有一个类似按钮【上线发布】，可以在这个按钮事件进行缓存，当然小伙伴们可根据自己的业务。

扣库存

一、秒杀扣库存，经常会出现【超卖】，这个是什么原因呢？我们看一下扣库存的代码：

直接执行sql语句，把库存减一。我们再看一下整体代码，先检查库存，有库存再扣库存。

//验证是否有库存
if(checkGoodStock(goodId) <= 0){
return 0; //表示无库存了
}
//扣库存
deductGoodStock(goodId);

二、举个例子：

如：我们现在的剩余库存为1，同时有2个线程请求过来，又同时执行到验证库存代码块，这样就都通过了验证，然后又先后执行了扣库存，但扣库存是直接减1的，导致库存变成了-1，超卖就此形成了。

核心导致超卖就是因为大量请求到来，引起并发问题；多个线程是被CPU调度执行的，各线程间交替执行业务。

怎么去解决这个问题？老顾之前介绍过分布式排他锁和乐观锁，都可以解决，可自行查阅。

三、这里因为业务表的设计，我们用另一种方式，稍微修改一下sql语句

DBUtils.ExecuteSql(" update goods set stock = stock - 1 where goodId = ? and stock > 0" , goodId);

在where语句加了stock > 0 ，因为update执行的时候产生行锁，其他线程只有等当前线程执行完后，才能去继续执行这个update语句。又因为加了stock > 0就保证了不可能出现负数出现超卖。

何时扣库存

一、扣库存业务有两个选择：

1、方案一：下单减库存，即当买家下单后，商品库存减去买家购买的数量

2、方案二：付款时库存，即当买家下单后，并不立即减库存，而是等用户付款后才减库存

这两个方案都有各自的问题，要从业务上面来分析。

1. 方案一的问题，下单就把库存减了，如有竞争对手通过恶意的方式将商品全部下单，让商品库存为0了，但最后他是不会付款的。这样导致正常的用户购买不了，卖家也没有得到钱。

2. 方案二有效解决了上面的问题，但是他出现的问题是，因为下单是不减库存的，只有付款后才减，那如果商品数量是10个，那很有可能有100个用户下了订单，都去付款支付，最后只有10个人能付款成功，90个人付款不了，这样就让用户体验很差，明明已经可以下单，但最后还是没有买到商品。

二、那怎么去选择？

一般我们在秒杀场景下我们选择方案一，小伙伴们有没有注意其他的平台，在下完单后，会有一定的时间去支付，一般设置半个小时。

其实本质就是让用户有半个小时支付时间，如超过不支付，就失效此订单，并且回收库存。

所以我们买家经常会去捡漏，这是很多系统常用的方式。

三、用户标记

即使有了上面的方案，其实还是会存在恶意的问题，只是我们把库存回收了。但还是有缓存的时间延迟半小时。
可在这基础上继续优化，加入风控系统，一般大中型平台都会有风控系统。这里老顾就讲最简单的方式。也就是我们要监控哪些用户一直是下单不付款的，如果超过一定的阀值，就给这个用户打上标记，归属黑名单。

还有就是在商品限制购买数量，经常使用的是每个用户限制购买1～2件，也能规避恶意下单。

分布式限流

秒杀场景一般都是商品稀缺，提供出来的数量比较少，如就100个，但很便宜，那就导致同一时间很多用户都会来抢，如100万用户来抢100个资源，其实有90%的用户请求是无效的，因为只有100个商品，也只有100个人能够买到。那100万个用户请求过来对系统来说是没有必要的，反而增加了系统压力。其实我们可以只允许5000个用户（业务评估出来的数值）进入业务系统，其他请求的直接返回就行了。

小伙伴们会不会说那不是不公平吗？其实大家仔细想想，秒杀拼的就是网络快，手快，和人品；没有什么公平不公平的

怎么解决？就是利用分布式限流方案，有很多中方案，Nginx限流，业务系统有计数器法，漏斗法，令牌法，网上有很多介绍；一般基于redis进行令牌限流，有很多组件，一般采用google提供的。老顾这里就不多作介绍，以后可以和大家专门分享限流知识点。

异步化

一、思路由来

我们大家想一想，即使我们做了上面的限流机制，卡住了绝大部分请求到业务系统中，但还是有很多请求进入了业务系统。如果我们商品库存数为5000个库存，在大流量的时候，会有很多用户都有资格去下单，那也就是同时会有5000个并发去操作mysql数据库。那数据库也是抗不住的，一般mysql的并发量500左右。

这个时候我们需要做一些异步处理，让5000个下单请求进入消息队列，让订单消费服务去慢慢处理5000个请求，这样就有效的把并发同步请求，改为了串行异步。

二、前端改造

当然改成了异步处理，前端在下单的时候，就没法立刻得到下单的结果，所以前端要做一个【抢购中。。。】的状态页面，在此页面中定时轮询下单结果。这样就大大提升了系统的吞吐量，降低了系统压力。

消息队列中间件有很多选择，一般选择RabbitMq，RocketMq。

总结

今天老顾把秒杀系统的核心知识点做了介绍，最主要的就是库存的处理思路，以及限流和异步化，商品详情其实是很重要的，大家要去看一下【你了解大型网站的页面静态化吗？】。

还有一些风控方面的知识没有介绍全，如：如何隐藏下单接口URL，规避恶意攻击。
其实这种大流量的系统，解决的核心思想就是：

1、尽量把请求拦截在最外层

2、保护数据库资源，尽量采用缓存

3、同步操作异步化

4、尽早失败，保护业务系统

谢谢大家！！！

持续关注我，分享更多干货。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

即使是面试跳槽，那也是一个学习的过程。只有全面的复习，才能让我们更好的充实自己，武装自己，为自己的面试之路不再坎坷！今天就给大家分享一个Github上全面的Java面试题大全，就是这份面试大全助我拿下大厂Offer，月薪提至30K！

我也是第一时间分享出来给大家，希望可以帮助大家都能去往自己心仪的大厂！为金三银四做准备！
一共有20个知识点专题，分别是：

Dubbo面试专题

JVM面试专题

Java并发面试专题

Kafka面试专题

MongDB面试专题

MyBatis面试专题

MySQL面试专题

Netty面试专题

RabbitMQ面试专题

Redis面试专题

Spring Cloud面试专题

SpringBoot面试专题

zookeeper面试专题

常见面试算法题汇总专题

计算机网络基础专题

设计模式专题

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
mg-FW6gYo84-1713737235379)]

设计模式专题

[外链图片转存中…(img-uhRsK5aT-1713737235379)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！