前言

高并发下如何设计秒杀零碎？这是一个高频面试题。这个问题看似简略，然而外面的水很深，它考查的是高并发场景下，从前端到后端多方面的常识。

秒杀个别呈现在商城的促销流动中，指定了肯定数量（比方：10个）的商品（比方：手机），以极低的价格（比方：0.1元），让大量用户参加流动，但只有极少数用户可能购买胜利。这类流动商家绝大部分是不赚钱的，说白了是找个噱头宣传本人。

虽说秒杀只是一个促销流动，但对技术要求不低。上面给大家总结一下设计秒杀零碎须要留神的9个细节。

1 刹时高并发

个别在秒杀工夫点（比方：12点）前几分钟，用户并发量才真正突增，达到秒杀工夫点时，并发量会达到高峰。

但因为这类流动是大量用户抢大量商品的场景，必定会呈现狼多肉少的状况，所以其实绝大部分用户秒杀会失败，只有极少局部用户可能胜利。

失常状况下，大部分用户会收到商品曾经抢完的揭示，收到该揭示后，他们大概率不会在那个流动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值继续的工夫其实是十分短的，这样就会呈现刹时高并发的状况，上面用一张图直观的感受一下流量的变动：

像这种刹时高并发的场景，传统的零碎很难应答，咱们须要设计一套全新的零碎。能够从以下几个方面动手：

  1. 页面动态化
  2. CDN减速
  3. 缓存
  4. mq异步解决
  5. 限流
  6. 分布式锁

2. 页面动态化

流动页面是用户流量的第一入口，所以是并发量最大的中央。

如果这些流量都能间接拜访服务端，恐怕服务端会因为承受不住这么大的压力，而间接挂掉。

流动页面绝大多数内容是固定的，比方：商品名称、商品形容、图片等。为了缩小不必要的服务端申请，通常状况下，会对流动页面做动态化解决。用户浏览商品等惯例操作，并不会申请到服务端。只有到了秒杀工夫点，并且用户被动点了秒杀按钮才容许拜访服务端。

这样能过滤大部分有效申请。

但只做页面动态化还不够，因为用户散布在全国各地，有些人在北京，有些人在成都，有些人在深圳，地区相差很远，网速各不相同。

如何能力让用户最快拜访到流动页面呢？

这就须要应用CDN，它的全称是Content Delivery Network，即内容散发网络。

使用户就近获取所需内容，升高网络拥塞，进步用户拜访响应速度和命中率。

3 秒杀按钮

大部分用户怕错过秒杀工夫点，个别会提前进入流动页面。此时看到的秒杀按钮是置灰，不可点击的。只有到了秒杀工夫点那一时刻，秒杀按钮才会主动点亮，变成可点击的。

但此时很多用户曾经急不可待了，通过不停刷新页面，争取在第一工夫看到秒杀按钮的点亮。

从后面得悉，该流动页面是动态的。那么咱们在动态页面中如何管制秒杀按钮，只在秒杀工夫点时才点亮呢？

没错，应用js文件管制。

为了性能思考，个别会将css、js和图片等动态资源文件提前缓存到CDN上，让用户可能就近拜访秒杀页面。

看到这里，有些聪慧的小伙伴，可能会问：CDN上的js文件是如何更新的？

秒杀开始之前，js标记为false，还有另外一个随机参数。当秒杀开始的时候零碎会生成一个新的js文件，此时标记为true，并且随机参数生成一个新值，而后同步给CDN。因为有了这个随机参数，CDN不会缓存数据，每次都能从CDN中获取最新的js代码。此外，前端还能够加一个定时器，管制比方：10秒之内，只容许发动一次申请。如果用户点击了一次秒杀按钮，则在10秒之内置灰，不容许再次点击，等到过了工夫限度，又容许从新点击该按钮。

4 读多写少

在秒杀的过程中，零碎个别会先查一下库存是否足够，如果足够才容许下单，写数据库。如果不够，则间接返回该商品曾经抢完。

因为大量用户抢大量商品，只有极少局部用户可能抢胜利，所以绝大部分用户在秒杀时，库存其实是有余的，零碎会间接返回该商品曾经抢完。

这是十分典型的：读多写少 的场景。

如果有数十万的申请过去，同时通过数据库查缓存是否足够，此时数据库可能会挂掉。因为数据库的连贯资源十分无限，比方：mysql，无奈同时反对这么多的连贯。

而应该改用缓存，比方：redis。

即使用了redis，也须要部署多个节点。

5 缓存问题

通常状况下，咱们须要在redis中保留商品信息，外面蕴含：商品id、商品名称、规格属性、库存等信息，同时数据库中也要有相干信息，毕竟缓存并不齐全牢靠。

用户在点击秒杀按钮，申请秒杀接口的过程中，须要传入的商品id参数，而后服务端须要校验该商品是否非法。

大抵流程如下图所示：

依据商品id，先从缓存中查问商品，如果商品存在，则参加秒杀。如果不存在，则须要从数据库中查问商品，如果存在，则将商品信息放入缓存，而后参加秒杀。如果商品不存在，则间接提醒失败。

这个过程外表上看起来是OK的，然而如果深入分析一下会发现一些问题。

5.1 缓存击穿

比方商品A第一次秒杀时，缓存中是没有数据的，但数据库中有。虽说下面有如果从数据库中查到数据，则放入缓存的逻辑。

然而，在高并发下，同一时刻会有大量的申请，都在秒杀同一件商品，这些申请同时去查缓存中没有数据，而后又同时拜访数据库。后果喜剧了，数据库可能扛不住压力，间接挂掉。

如何解决这个问题呢？

这就须要加锁，最好应用分布式锁。

当然，针对这种状况，最好在我的项目启动之前，先把缓存进行预热。即当时把所有的商品，同步到缓存中，这样商品根本都能间接从缓存中获取到，就不会呈现缓存击穿的问题了。

是不是下面加锁这一步能够不须要了？

外表上看起来，的确能够不须要。但如果缓存中设置的过期工夫不对，缓存提前过期了，或者缓存被不小心删除了，如果不减速同样可能呈现缓存击穿。

其实这里加锁，相当于买了一份保险。

5.2 缓存穿透

如果有大量的申请传入的商品id，在缓存中和数据库中都不存在，这些申请不就每次都会穿透过缓存，而间接拜访数据库了。

因为后面曾经加了锁，所以即便这里的并发量很大，也不会导致数据库间接挂掉。

但很显然这些申请的解决性能并不好，有没有更好的解决方案？

这时能够想到布隆过滤器。

零碎依据商品id，先从布隆过滤器中查问该id是否存在，如果存在则容许从缓存中查问数据，如果不存在，则间接返回失败。

虽说该计划能够解决缓存穿透问题，然而又会引出另外一个问题：布隆过滤器中的数据如何更缓存中的数据保持一致？

这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器中。如果数据同步失败了，还须要减少重试机制，而且跨数据源，能保证数据的实时一致性吗？

显然是不行的。

所以布隆过滤器绝大部分应用在缓存数据更新很少的场景中。

如果缓存数据更新十分频繁，又该如何解决呢？

这时，就须要把不存在的商品id也缓存起来。

下次，再有该商品id的申请过去，则也能从缓存中查到数据，只不过该数据比拟非凡，示意商品不存在。须要特地留神的是，这种非凡缓存设置的超时工夫应该尽量短一点。

6 库存问题

对于库存问题看似简略，实则外面还是有些货色。

真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没实现领取，扣减的库存是要加回去的。

所以，在这里引出了一个预扣库存的概念，预扣库存的次要流程如下：

扣减库存中除了下面说到的预扣库存和回退库存之外，还须要特地留神的是库存有余和库存超卖问题。

6.1 数据库扣减库存

应用数据库扣减库存，是最简略的实现计划了，假如扣减库存的sql如下：

update product set stock=stock-1 where id=123;

这种写法对于扣减库存是没有问题的，但如何管制库存有余的状况下，不让用户操作呢？

这就须要在update之前，先查一下库存是否足够了。

伪代码如下：

int stock = mapper.getStockById(123);if(stock > 0) {  int count = mapper.updateStock(123);  if(count > 0) {    addOrder(123);  }}

大家有没有发现这段代码的问题？

没错，查问操作和更新操作不是原子性的，会导致在并发的场景下，呈现库存超卖的状况。

有人可能会说，这样好办，加把锁，不就搞定了，比方应用synchronized关键字。

的确，能够，然而性能不够好。

还有更优雅的解决计划，即基于数据库的乐观锁，这样会少一次数据库查问，而且可能人造的保证数据操作的原子性。

只需将下面的sql略微调整一下：

update product set stock=stock-1 where id=product and stock > 0;

在sql最初加上：stock > 0，就能保障不会呈现超卖的状况。

但须要频繁拜访数据库，咱们都晓得数据库连贯是十分低廉的资源。在高并发的场景下，可能会造成零碎雪崩。而且，容易呈现多个申请，同时竞争行锁的状况，造成互相期待，从而呈现死锁的问题。

6.2 redis扣减库存

redis的incr办法是原子性的，能够用该办法扣减库存。伪代码如下：

 boolean exist = redisClient.query(productId,userId);  if(exist) {    return -1;  }  int stock = redisClient.queryStock(productId);  if(stock <=0) {    return 0;  }  redisClient.incrby(productId, -1);  redisClient.add(productId,userId);return 1;

代码流程如下：

  1. 先判断该用户有没有秒杀过该商品，如果曾经秒杀过，则间接返回-1。
  2. 查问库存，如果库存小于等于0，则间接返回0，示意库存有余。
  3. 如果库存短缺，则扣减库存，而后将本次秒杀记录保存起来。而后返回1，示意胜利。

预计很多小伙伴，一开始都会按这样的思路写代码。但如果认真想想会发现，这段代码有问题。

有什么问题呢？

如果在高并发下，有多个申请同时查问库存，过后都大于0。因为查问库存和更新库存非准则操作，则会呈现库存为正数的状况，即库存超卖。

当然有人可能会说，加个synchronized不就解决问题？

调整后代码如下：

   boolean exist = redisClient.query(productId,userId);   if(exist) {    return -1;   }   synchronized(this) {       int stock = redisClient.queryStock(productId);       if(stock <=0) {         return 0;       }       redisClient.incrby(productId, -1);       redisClient.add(productId,userId);   }return 1;

加synchronized的确能解决库存为正数问题，然而这样会导致接口性能急剧下降，每次查问都须要竞争同一把锁，显然不太正当。

为了解决下面的问题，代码优化如下：

boolean exist = redisClient.query(productId,userId);if(exist) {  return -1;}if(redisClient.incrby(productId, -1)<0) {  return 0;}redisClient.add(productId,userId);return 1;

该代码次要流程如下：

  1. 先判断该用户有没有秒杀过该商品，如果曾经秒杀过，则间接返回-1。
  2. 扣减库存，判断返回值是否小于0，如果小于0，则间接返回0，示意库存有余。
  3. 如果扣减库存后，返回值大于或等于0，则将本次秒杀记录保存起来。而后返回1，示意胜利。

该计划咋一看，如同没问题。

但如果在高并发场景中，有多个申请同时扣减库存，大多数申请的incrby操作之后，后果都会小于0。

虽说，库存呈现正数，不会呈现超卖的问题。但因为这里是预减库存，如果负数值负的太多的话，前面万一要回退库存时，就会导致库存不准。

那么，有没有更好的计划呢？

6.3 lua脚本扣减库存

咱们都晓得lua脚本，是可能保障原子性的，它跟redis一起配合应用，可能完满解决下面的问题。

lua脚本有段十分经典的代码：

  StringBuilder lua = new StringBuilder();  lua.append("if (redis.call('exists', KEYS[1]) == 1) then");  lua.append("    local stock = tonumber(redis.call('get', KEYS[1]));");  lua.append("    if (stock == -1) then");  lua.append("        return 1;");  lua.append("    end;");  lua.append("    if (stock > 0) then");  lua.append("        redis.call('incrby', KEYS[1], -1);");  lua.append("        return stock;");  lua.append("    end;");  lua.append("    return 0;");  lua.append("end;");  lua.append("return -1;");

该代码的次要流程如下：

  1. 先判断商品id是否存在，如果不存在则间接返回。
  2. 获取该商品id的库存，判断库存如果是-1，则间接返回，示意不限度库存。
  3. 如果库存大于0，则扣减库存。
  4. 如果库存等于0，是间接返回，示意库存有余。

7 分布式锁

之前我提到过，在秒杀的时候，须要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，而后返回。如果数据库中没有，则间接返回失败。

大家试想一下，如果在高并发下，有大量的申请都去查一个缓存中不存在的商品，这些申请都会间接打到数据库。数据库因为承受不住压力，而间接挂掉。

那么如何解决这个问题呢？

这就须要用redis分布式锁了。

7.1 setNx加锁

应用redis的分布式锁，首先想到的是setNx命令。

if (jedis.setnx(lockKey, val) == 1) {   jedis.expire(lockKey, timeout);}

用该命令其实能够加锁，但和前面的设置超时工夫是离开的，并非原子操作。

如果加锁胜利了，然而设置超时工夫失败了，该lockKey就变成永不生效的了。在高并发场景中，该问题会导致十分重大的结果。

那么，有没有保障原子性的加锁命令呢？

7.2 set加锁

应用redis的set命令，它能够指定多个参数。

String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);if ("OK".equals(result)) {    return true;}return false;

其中：

  • lockKey：锁的标识
  • requestId：申请id
  • NX：只在键不存在时，才对键进行设置操作。
  • PX：设置键的过期工夫为 millisecond 毫秒。
  • expireTime：过期工夫

因为该命令只有一步，所以它是原子操作。

7.3 开释锁

接下来，有些敌人可能会问：在加锁时，既然曾经有了lockKey锁标识，为什么要须要记录requestId呢？

答：requestId是在开释锁的时候用的。

if (jedis.get(lockKey).equals(requestId)) {    jedis.del(lockKey);    return true;}return false;

在开释锁的时候，只能开释本人加的锁，不容许开释他人加的锁。

这里为什么要用requestId，用userId不行吗？

答：如果用userId的话，假如本次申请流程走完了，筹备删除锁。此时，偶合锁到了过期工夫生效了。而另外一个申请，偶合应用的雷同userId加锁，会胜利。而本次申请删除锁的时候，删除的其实是他人的锁了。

当然应用lua脚本也能防止该问题：

if redis.call('get', KEYS[1]) == ARGV[1] then  return redis.call('del', KEYS[1]) else   return 0 end

它能保障查问锁是否存在和删除锁是原子操作。

7.4 自旋锁

下面的加锁办法看起来如同没有问题，但如果你认真想想，如果有1万的申请同时去竞争那把锁，可能只有一个申请是胜利的，其余的9999个申请都会失败。

在秒杀场景下，会有什么问题？

答：每1万个申请，有1个胜利。再1万个申请，有1个胜利。如此上来，直到库存有余。这就变成均匀分布的秒杀了，跟咱们设想中的不一样。

如何解决这个问题呢？

答：应用自旋锁。

try {  Long start = System.currentTimeMillis();  while(true) {      String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);     if ("OK".equals(result)) {        return true;     }          long time = System.currentTimeMillis() - start;      if (time>=timeout) {          return false;      }      try {          Thread.sleep(50);      } catch (InterruptedException e) {          e.printStackTrace();      }  } } finally{    unlock(lockKey,requestId);}  return false;

在规定的工夫，比方500毫秒内，自旋一直尝试加锁，如果胜利则间接返回。如果失败，则休眠50毫秒，再发动新一轮的尝试。如果到了超时工夫，还未加锁胜利，则间接返回失败。

7.5 redisson

除了下面的问题之外，应用redis分布式锁，还有锁竞争问题、续期问题、锁重入问题、多个redis实例加锁问题等。

这些问题应用redisson能够解决，因为篇幅的起因，在这里先保留一点悬念，有疑难的私聊给我。前面会出一个专题介绍分布式锁，敬请期待。

8 mq异步解决

咱们都晓得在实在的秒杀场景中，有三个外围流程：而这三个外围流程中，真正并发量大的是秒杀性能，下单和领取性能理论并发量很小。所以，咱们在设计秒杀零碎时，有必要把下单和领取性能从秒杀的主流程中拆分进去，特地是下单功能要做成mq异步解决的。而领取性能，比方支付宝领取，是业务场景自身保障的异步。

于是，秒杀后下单的流程变成如下：如果应用mq，须要关注以下几个问题：

8.1 音讯失落问题

秒杀胜利了，往mq发送下单音讯的时候，有可能会失败。起因有很多，比方：网络问题、broker挂了、mq服务端磁盘问题等。这些状况，都可能会造成音讯失落。

那么，如何避免音讯失落呢？

答：加一张音讯发送表。

在生产者发送mq音讯之前，先把该条音讯写入音讯发送表，初始状态是待处理，而后再发送mq音讯。消费者生产音讯时，解决完业务逻辑之后，再回调生产者的一个接口，批改音讯状态为已解决。

如果生产者把音讯写入音讯发送表之后，再发送mq音讯到mq服务端的过程中失败了，造成了音讯失落。

这时候，要如何解决呢？

答：应用job，减少重试机制。

用job每隔一段时间去查问音讯发送表中状态为待处理的数据，而后从新发送mq音讯。

8.2 反复生产问题

原本消费者生产音讯时，在ack应答的时候，如果网络超时，自身就可能会生产反复的音讯。但因为音讯发送者减少了重试机制，会导致消费者反复音讯的概率增大。

那么，如何解决反复音讯问题呢？

答：加一张音讯处理表。

消费者读到音讯之后，先判断一下音讯处理表，是否存在该音讯，如果存在，示意是反复生产，则间接返回。如果不存在，则进行下单操作，接着将该音讯写入音讯处理表中，再返回。

有个比拟要害的点是：下单和写音讯处理表，要放在同一个事务中，保障原子操作。

8.3 垃圾音讯问题

这套计划外表上看起来没有问题，但如果呈现了音讯生产失败的状况。比方：因为某些起因，音讯消费者下单始终失败，始终不能回调状态变更接口，这样job会不停的重试发消息。最初，会产生大量的垃圾音讯。

那么，如何解决这个问题呢？每次在job重试时，须要先判断一下音讯发送表中该音讯的发送次数是否达到最大限度，如果达到了，则间接返回。如果没有达到，则将次数加1，而后发送音讯。

这样如果出现异常，只会产生大量的垃圾音讯，不会影响到失常的业务。

8.4 提早生产问题

通常状况下，如果用户秒杀胜利了，下单之后，在15分钟之内还未实现领取的话，该订单会被主动勾销，回退库存。

那么，在15分钟内未实现领取，订单被主动勾销的性能，要如何实现呢？

咱们首先想到的可能是job，因为它比较简单。

但job有个问题，须要每隔一段时间解决一次，实时性不太好。

还有更好的计划？

答：应用提早队列。

咱们都晓得rocketmq，自带了提早队列的性能。

下单时音讯生产者会学生成订单，此时状态为待领取，而后会向提早队列中发一条音讯。达到了延迟时间，音讯消费者读取音讯之后，会查问该订单的状态是否为待领取。如果是待领取状态，则会更新订单状态为勾销状态。如果不是待领取状态，阐明该订单曾经领取过了，则间接返回。

还有个关键点，用户实现领取之后，会批改订单状态为已领取。

9 如何限流？

通过秒杀流动，如果咱们运气爆棚，可能会用非常低的价格买到不错的商品（这种概率堪比买福利彩票中大奖）。

但有些高手，并不会像咱们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在本人的服务器上，模仿失常用户登录零碎，跳过秒杀页面，间接调用秒杀接口。

如果是咱们手动操作，个别状况下，一秒钟只能点击一次秒杀按钮。然而如果是服务器，一秒钟能够申请成上千接口。这种差距切实太显著了，如果不做任何限度，绝大部分商品可能是被机器抢到，而非正常的用户，有点不太偏心。

所以，咱们有必要辨认这些非法申请，做一些限度。那么，咱们该如何当初这些非法申请呢？

目前有两种罕用的限流形式：

  1. 基于nginx限流
  2. 基于redis限流

9.1 对同一用户限流

为了避免某个用户，申请接口次数过于频繁，能够只针对该用户做限度。限度同一个用户id，比方每分钟只能申请5次接口。

9.2 对同一ip限流

有时候只对某个用户限流是不够的，有些高手能够模仿多个用户申请，这种nginx就没法辨认了。

这时须要加同一ip限流性能。限度同一个ip，比方每分钟只能申请5次接口。

但这种限流形式可能会有误杀的状况，比方同一个公司或网吧的进口ip是雷同的，如果外面有多个失常用户同时发动申请，有些用户可能会被限制住。

9.3 对接口限流

别以为限度了用户和ip就高枕无忧，有些高手甚至能够应用代理，每次都申请都换一个ip。

这时能够限度申请的接口总次数。在高并发场景下，这种限度对于零碎的稳定性是十分有必要的。但可能因为有些非法申请次数太多，达到了该接口的申请下限，而影响其余的失常用户拜访该接口。看起来有点得失相当。

9.4 加验证码

绝对于下面三种形式，加验证码的形式可能更精准一些，同样能限度用户的拜访频次，但益处是不会存在误杀的状况。

通常状况下，用户在申请之前，须要先输出验证码。用户发动申请之后，服务端会去校验该验证码是否正确。只有正确才容许进行下一步操作，否则间接返回，并且提醒验证码谬误。

此外，验证码个别是一次性的，同一个验证码只容许应用一次，不容许重复使用。

一般验证码，因为生成的数字或者图案比较简单，可能会被破解。长处是生成速度比拟快，毛病是有安全隐患。

还有一个验证码叫做：挪动滑块，它生成速度比较慢，但比拟平安，是目前各大互联网公司的首选。

9.5 进步业务门槛

下面说的加验证码尽管能够限度非法用户申请，然而有些影响用户体验。用户点击秒杀按钮前，还要先输出验证码，流程显得有点繁琐，秒杀性能的流程不是应该越简略越好吗？

其实，有时候达到某个目标，不肯定非要通过技术手段，通过业务伎俩也一样。

12306刚开始的时候，全国人民都在同一时刻抢火车票，因为并发量太大，零碎常常挂。起初，重构优化之后，将购买周期放长了，能够提前20天购买火车票，并且能够在9点、10、11点、12点等整点购买火车票。调整业务之后（当然技术也有很多调整），将之前集中的申请，扩散开了，一下子升高了用户并发量。

回到这里，咱们通过进步业务门槛，比方只有会员能力参加秒杀流动，一般注册用户没有权限。或者，只有等级达到3级以上的普通用户，才有资格加入该流动。

这样简略的进步一点门槛，即便是黄牛党也大刀阔斧，他们总不可能为了加入一次秒杀流动，还另外花钱充值会员吧？

最初说一句(求关注，别白嫖我)

如果这篇文章对您有所帮忙，或者有所启发的话，帮忙扫描下发二维码关注一下，您的反对是我保持写作最大的能源。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：面试、代码神器、开发手册、工夫治理有超赞的粉丝福利，另外回复：加群，能够跟很多BAT大厂的前辈交换和学习。