如何设计一个秒杀系统

什么是秒杀

秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品，电商网站一般会在约定时间点对其进行限量销售，因为这些商品的特殊性，会吸引大量用户前来抢购，并且会在约定的时间点同时在秒杀页面进行抢购。

秒杀系统场景特点

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

秒杀架构设计理念

限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。

削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。

可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。

架构方案

一般秒杀系统架构

设计思路

将请求拦截在系统上游，降低下游压力：秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。 
充分利用缓存：利用缓存可极大提高系统读写速度。 
消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。

前端方案

浏览器端(js)：

页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。 
禁止重复提交：用户提交之后按钮置灰，禁止重复提交 
用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流

后端方案

服务端控制器层(网关层)

限制uid（UserID）访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率。

服务层

上面只拦截了一部分访问请求，当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。

1. 采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。

2. 利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。

3. 利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

数据库层

数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。

案例：利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。

当然，上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等，也可以将缓存和消息中间件 组合起来，缓存系统负责接收记录用户请求，消息中间件负责将缓存中的请求同步到数据库。

 

 

秒杀中的最大压力就是对商品库存的并发争抢，就像商场大促销，就那么两件，一堆大妈冲上去抢，各个身怀绝技，商场导购小妹没点武艺还真是抗不住。这时候可以参考之前文章中的异步减库存的形式来做，只是这里是异步下订单。说具体方案之前，先看看这个业务场景要做什么？其实就是在解决一万个人同时拿着钱来东西，但是东西只有十件，你卖给谁的问题，只要没给钱，那我东西不给你就没问题，给了钱就必须拿到东西。所以这里我们可以对来买东西的人强制他们排队，先到先得，并且排队的数据少量丢失是可以接受的，后面拍着那么多人呢，不怕卖不完。那最后的方案就是，用户点击秒杀按钮后，加入秒杀队列（限制长度），加入成功则告知正在秒杀，否则直接跳到秒杀结束页面。对于秒杀队列中的用户，则进行写订单减库存处理处理，并且记录成功与失败，商品秒杀完成后，标记秒杀结束，并且可以清空秒杀队列，避免后面重复判断和处理。用户端轮询（可以采用长轮询，时效性好）结果，如果秒杀结束并且自己没有秒杀成功，则跳转到秒杀结束页面，否则继续等待，如果秒杀成功则跳转到秒杀成功页面，支付就是后面的事情了。这里有几个点需要关注，一是作弊，就是验证码，各种策略各种造型的验证码；二是时效性，秒杀完后一段时间（比如半个小时）没付款，应该将该笔秒杀标记无效，并且把库存回补。消息中间件再次大显身手，秒杀队列，这里需要消息中间件提供限长队列功能（不限长，先查询再入队也是可以的，只是要把握好这个时间间隔可能加入的多余数据对消息中间件的影响），清空队列功能（没有也可以，只是不能更快的释放压力）。当然除了这些，还有限流功能，接入层只允许系统可负载流量进入，超过一定负载就采取措施缓解流量进入（比如验证码。。。）。可以看到，对于秒杀中功能，基本就是采取逐级降低流量的方法（大流量系统的重要思路），只让不过分高于有效流量的流量进入后端真正的业务系统，保证业务系统不宕机。还有一个原则就是读比写更容易扩展，无业务系统比业务系统更容易扩展，所以应该化写为读（下订单变为查询订单），降低业务系统压力（前端接入层拦截无效流量）。