一、初始方案

商品表设计：热销商品提供给用户秒杀，有初始库存。

 

秒杀订单表设计：记录秒杀成功的订单情况：

 

Dao设计：主要就是一个减少库存方法，其他CRUD使用JPA自带的方法：

 

数据初始化以及提供保存订单的操作：

 

 

下面就是controller层的设计：

 

上面是全部的基础准备，下面使用一个单元测试方法，模拟高并发下，很多人来购买同一个热门商品的情况。

 

 

访问localhost:8080/simulationCocurrentTakeOrder，就可以测试了

预期情况：因为我们只对秒杀商品（123456）初始化了10件，理想情况当然是库存减少到0，订单表也只有10条记录。

1、实际情况：订单表记录

 

2、商品表记录

 

3、下面分析一下为啥会出现超库存的情况：

因为多个请求访问，仅仅是使用dao查询了一次数据库有没有库存，但是比较恶劣的情况是很多人都查到了有库存，这个时候因为程序处理的延迟，没有及时的减少库存，那就出现了脏读。如何在设计上避免呢？

最笨的方法是对SecKillController的seckill方法做同步，每次只有一个人能下单。但是太影响性能了，下单变成了同步操作。

 

二、改进方案

根据多线程编程的规范，提倡对共享资源加锁，在最有可能出现并发争抢的情况下加同步块的思想。应该同一时刻只有一个线程去减少库存。但是这里给出一个最好的方案，就是利用Oracle,MySQL的行级锁–同一时间只有一个线程能够操作同一行记录，对SecKillGoodsDao进行改造：

 

仅仅是加了一个and，却造成了很大的改变，返回int值代表的是影响的行数，对应到controller做出相应的判断。

 

在看看运行情况

 

订单表：

 

在高并发问题下的秒杀情况，即使存在网络延时，也得到了保障。

扩展阅读

高并发系统的设计及秒杀实践

缓存在高并发场景下的常见问题

对高并发流量控制的一点思考

高可用高并发的 9 种技术架构！

Redis 的各项功能解决了哪些问题？

设计抗住千万级流量的架构思路

来源：https://blog.csdn.net/u013815546/article/details/53928912