高并发秒杀系统解决方案

秒杀系统场景特点

1, 秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增。
2, 秒杀一般是访问请求数量远远大于库存数量，只有少部分用户能够秒杀成功。
3, 秒杀业务流程比较简单，一般就是下订单减库存。

秒杀系统技术要求

1, 高并发：秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增。是时间极短、瞬间用户量极大。面对瞬间的流量涌入，如何保证服务还能平稳运行。

2, 超卖：高效益的产品不可能无限量供应，在总额度有限的前提下，如果发生超卖的情况，不仅会损失金钱，也会引发用户投诉，降低用户口碑。

3, 恶意请求：对于恶意的请求，即便不法用户最后未能抢到商品，但在恶意请求的期间，这种行为也会给服务器、数据库、带宽等造成压力，导致其他用户体验下降，对于脚本等恶意行为应该迅速拦截。

4, 数据库：项目使用 MySQL 数据库，在高 QPS 的场景下，如果流量瞬间涌入数据库后让数据库挂掉，导致其他服务也无法使用，带来的灾难将是不可预估的。

5, 链接暴露：为了防止不法分子提前知道秒杀活动的地址并发起请求，需设计一个随机算法生成秒杀链接。

同时还有以下问题需要被考虑：
时间同步：多个客户端的时间保持同步，也就是让大家看到时间是一致的。
高可扩：随着时间的推移，系统可能对功能，性能等方面有新的要求。

技术方案

很明显，要让大规模用户能够同时打开抢货的网页，势必要用要到 CDN。同时利用我们分布式中限流、网关等知识，将请求层层筛选，降低最后连接到数据库的请求。即使用 CDN 的边缘结点来扛流量，然后过滤用户请求（限流用户请求），来保护数据中心的系统。

CDN 主要作用有两个：

• 将一些不会改变的静态资源放到离客户端较近的边缘服务器上。这样客户端请求数据的时候可以直接从边缘服务器获取，降低中心服务器的压力。

• 可以把小服务部署到 CDN 结点上去，这样，当前端页面来访问开没开始时，这个小服务除了告诉前端是否开始外，它还可以统计下有多少人在线。

每个小服务会把当前在线等待秒杀的人数每隔一段时间就回传给我们的数据中心，于是我们就知道全网总共在线的人数有多少。

利用 CDN 将静态资源分发在边缘服务器上，当进行服务请求时，先进行鉴权，鉴权主要是筛选机器人等非人工抢购，根据实际经验，鉴权可以筛选很大一部分用户，例如是否登录。

当鉴权确定是真实有效的用户之后，通过负载均衡，也就是 LVS+Keepalived 将请求分配到不同的 Nginx 上。

一般会建立 Nginx 集群，然后再通过网关集群，即使这样还是要增加一些限流措施。

如果到这一步还是有很多请求压到数据库势必撑不住，那么可以采取服务限流、服务降级等措施，进行削峰处理。

到这儿理论上流量就不高了，如果还是很高，后面就将热点数据放进缓存集群中进行预热，同时设置定时任务。

一方面关注数据库与缓存的一致性，另一方面关闭超时未支付的订单，当订单提交之后交给任务队列，生成订单、修改数据库、做好持久化工作。

架构图如下（可点击查看大图）：

针对超卖问题

1. 超卖的原因

假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。

在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。

2. 悲观锁思路

解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。

悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。

3. 乐观锁思路

这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑