高并发下的下单功能设计
一、初始方案
商品表设计：热销商品提供给用户秒杀，有初始库存。
秒杀订单表设计：记录秒杀成功的订单情况：
Dao设计：主要就是一个减少库存方法，其他CRUD使用JPA自带的方法：
数据初始化以及提供保存订单的操作：
下面就是controller层的设计：
上面是全部的基础准备，下面使用一个单元测试方法，模拟高并发下，很多人来购买同一个热门商品的情况。
访问localhost:8080/simulationCocurrentTakeOrder，就可以测试了
预期情况：因为我们只对秒杀商品（123456）初始化了10件，理想情况当然是库存减少到0，订单表也只有10条记录。
1、实际情况：订单表记录
2、商品表记录
3、下面分析一下为啥会出现超库存的情况：
因为多个请求访问，仅仅是使用dao查询了一次数据库有没有库存，但是比较恶劣的情况是很多人都查到了有库存，这个时候因为程序处理的延迟，没有及时的减少库存，那就出现了脏读。如何在设计上避免呢？
最笨的方法是对SecKillController的seckill方法做同步，每次只有一个人能下单。但是太影响性能了，下单变成了同步操作。
二、改进方案
根据多线程编程的规范，提倡对共享资源加锁，在最有可能出现并发争抢的情况下加同步块的思想。应该同一时刻只有一个线程去减少库存。但是这里给出一个最好的方案，就是利用Oracle,MySQL的行级锁–同一时间只有一个线程能够操作同一行记录，对SecKillGoodsDao进行改造：
仅仅是加了一个and，却造成了很大的改变，返回int值代表的是影响的行数，对应到controller做出相应的判断。
在看看运行情况
订单表：
在高并发问题下的秒杀情况，即使存在网络延时，也得到了保障。
扩展阅读
来源：https://blog.csdn.net/u013815546/article/details/53928912
