关于后端:面试必考秒杀系统要如何设计

前言

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

秒杀个别呈现在商城的促销流动中,指定了肯定数量(比方: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大厂的前辈交换和学习。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年99元

阿里云限时活动-1核2G-1M带宽-40-100G ,特惠价87.12元/年(原价1234.2元/年,可以直接买3年),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据