秒杀系统的设计与实现（一）

1.1 秒杀场景

电商抢购限量商品
卖周董演唱会的门票
火车票抢座 12306
…

1.2 为什么要做个系统

如果你的项目流量非常小，完全不用担心有并发的购买请求，那么做这样一个系统意义不大。但如果系统要像12306那样，接受高并发访问和下单的考验，那么就需要一套完整的流程保护措施，来保证你系统在用户流量高峰期不会被搞挂了

严格防止超卖：库存100件你卖了120件，等着辞职吧

-防止黑产：防止不怀好意的人群通过各种技术手段把你本该下发给群众的利益全收入了囊中。

保证用户体验：高并发下，网页打不开了，支付不成功了，购物车进不去了，地址改不了了

1.3 保护措施有哪些

乐观锁防止超卖 —核心基础
令牌桶限流
Redis 缓存
消息队列异步处理订单
…

防止超卖：

悲观锁版本

使用synchronized(同步代码块)时需要注意，synchronized的锁会与事务的锁产生冲突，

解决方法1：可以把事务那个锁加在方法上面就好了，
解决方法2：把同步代码块放在具体的位置(也就是controller调用的位置)

上面使用的同步代码块是悲观锁的方式，这种锁有点低在实际生产中，并不推荐，下面是乐观锁

使用乐观锁解决商品超卖

说明：使用乐观锁解决商品超卖问题，实际上是把主要防止超卖问题交给了数据库去解决，利用了数据库中得version字段以及数据库中的事务实现，在并发情况下商品的超卖问题，
改造了业务层，将每一个方法剥离了出来。

更新了扣除库存的方法，使其在sql层进行更新 其他两个方法不变。

上面这种方式出现了一个问题，，因为每一个请求只执行一次，而sql这边能不能成功全凭运气，当人数较少时，可能会出现卖不完的情况。后面解决