高并发秒杀系统架构详解,不是所有的秒杀都是秒杀!

写在前面

很多小伙伴反馈说,高并发专题学了那么久,但是,在真正做项目时,仍然不知道如何下手处理高并发业务场景!甚至很多小伙伴仍然停留在只是简单的提供接口(CRUD)阶段,不知道学习的并发知识如何运用到实际项目中,就更别提如何构建高并发系统了!

究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构,结合高并发专题下的其他文章,学以致用。

这边还有各个知识点模块整理文档和更多大厂面试真题,有需要的朋友可以加q群:1103806531  备注:简书   免费领取~

电商系统架构

在电商领域,存在着典型的秒杀业务场景,那何谓秒杀场景呢。简单的来说就是一件商品的购买人数远远大于这件商品的库存,而且这件商品在很短的时间内就会被抢购一空。 比如每年的618、双11大促,小米新品促销等业务场景,就是典型的秒杀业务场景。

我们可以将电商系统的架构简化成下图所示。

由图所示,我们可以简单的将电商系统的核心层分为:负载均衡层、应用层和持久层。接下来,我们就预估下每一层的并发量。

假如负载均衡层使用的是高性能的Nginx,则我们可以预估Nginx最大的并发度为:10W+,这里是以万为单位。

假设应用层我们使用的是Tomcat,而Tomcat的最大并发度可以预估为800左右,这里是以百为单位。

假设持久层的缓存使用的是Redis,数据库使用的是MySQL,MySQL的最大并发度可以预估为1000左右,以千为单位。Redis的最大并发度可以预估为5W左右,以万为单位。

所以,负载均衡层、应用层和持久层各自的并发度是不同的,那么,为了提升系统的总体并发度和缓存,我们通常可以采取哪些方案呢?

(1)系统扩容

系统扩容包括垂直扩容和水平扩容,增加设备和机器配置,绝大多数的场景有效。

(2)缓存

本地缓存或者集中式缓存,减少网络IO,基于内存读取数据。大部分场景有效。

(3)读写分离

采用读写分离,分而治之,增加机器的并行处理能力。

秒杀系统的特点

秒杀系统的业务特点

秒杀系统的技术特点

由于篇幅有限,这一部分省略,需要完整版的朋友可以加q群:1103806531  备注:简书   免费领取~

秒杀三阶段

通常,从秒杀开始到结束,往往会经历三个阶段:

准备阶段:这个阶段也叫作系统预热阶段,此时会提前预热秒杀系统的业务数据,往往这个时候,用户会不断刷新秒杀页面,来查看秒杀活动是否已经开始。在一定程度上,通过用户不断刷新页面的操作,可以将一些数据存储到Redis中进行预热。

秒杀阶段:这个阶段主要是秒杀活动的过程,会产生瞬时的高并发流量,对系统资源会造成巨大的冲击,所以,在秒杀阶段一定要做好系统防护。

结算阶段: 完成秒杀后的数据处理工作,比如数据的一致性问题处理,异常情况处理,商品的回仓处理等。

针对这种短时间内大流量的系统来说,就不太适合使用系统扩容了,因为即使系统扩容了,也就是在很短的时间内会使用到扩容后的系统,大部分时间内,系统无需扩容即可正常访问。 那么,我们可以采取哪些方案来提升系统的秒杀性能呢?

秒杀系统方案

针对秒杀系统的特点,我们可以采取如下的措施来提升系统的性能。

(1)异步解耦

将整体流程进行拆解,核心流程通过队列方式进行控制。

(2)限流防刷

控制网站整体流量,提高请求的门槛,避免系统资源耗尽。

(3)资源控制

将整体流程中的资源调度进行控制,扬长避短。

由于应用层能够承载的并发量比缓存的并发量少很多。所以,在高并发系统中,我们可以直接使用OpenResty由负载均衡层访问缓存,避免了调用应用层的性能损耗。 同时,由于秒杀系统中,商品数量比较少,我们也可以使用动态渲染技术,CDN技术来加速网站的访问性能。

如果在秒杀活动开始时,并发量太高时,我们可以将用户的请求放入队列中进行处理,并为用户弹出排队页面。

秒杀系统时序图

网上很多的秒杀系统和对秒杀系统的解决方案,并不是真正的秒杀系统,他们采用的只是同步处理请求的方案,一旦并发量真的上来了,他们所谓的秒杀系统的性能会急剧下降。我们先来看一下秒杀系统在同步下单时的时序图。

同步下单流程

1.用户发起秒杀请求

在同步下单流程中,首先,用户发起秒杀请求。商城服务需要依次执行如下流程来处理秒杀请求的业务。

(1)识别验证码是否正确

商城服务判断用户发起秒杀请求时提交的验证码是否正确。

(2)判断活动是否已经结束

验证当前秒杀活动是否已经结束。

(3)验证访问请求是否处于黑名单

在电商领域中,存在着很多的恶意竞争,也就是说,其他商家可能会通过不正当手段来恶意请求秒杀系统,占用系统大量的带宽和其他系统资源。此时,就需要使用风控系统等实现黑名单机制。为了简单,也可以使用拦截器统计访问频次实现黑名单机制。

(4)验证真实库存是否足够

系统需要验证商品的真实库存是否足够,是否能够支持本次秒杀活动的商品库存量。

(5)扣减缓存中的库存

在秒杀业务中,往往会将商品库存等信息存放在缓存中,此时,还需要验证秒杀活动使用的商品库存是否足够,并且需要扣减秒杀活动的商品库存数量。

(6)计算秒杀的价格

由于在秒杀活动中,商品的秒杀价格和商品的真实价格存在差异,所以,需要计算商品的秒杀价格。

注意:如果在秒杀场景中,系统涉及的业务更加复杂的话,会涉及更多的业务操作,这里,我只是列举出一些常见的业务操作。

2.提交订单

(1)订单入口

将用户提交的订单信息保存到数据库中。

(2)扣减真实库存

订单入库后,需要在商品的真实库存中将本次成功下单的商品数量扣除。

如果我们使用上述流程开发了一个秒杀系统,当用户发起秒杀请求时,由于系统每个业务流程都是串行执行的,整体上系统的性能不会太高,当并发量太高时,我们会为用户弹出下面的排队页面,来提示用户进行等待。

由于时间关系,没有写的很详细,有需要完整版的朋友可以加q群:1103806531  备注:简书   免费领取~

高并发“黑科技”与致胜奇招

假设,在秒杀系统中我们使用Redis实现缓存,假设Redis的读写并发量在5万左右。我们的商城秒杀业务需要支持的并发量在100万左右。如果这100万的并发全部打入Redis中,Redis很可能就会挂掉,那么,我们如何解决这个问题呢?

留下这个问题,欢迎大家在评论区交流~