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

前言

很多小伙伴反馈说,高并发专题学了那么久,但是,在真正做项目时,仍然不知道如何下手处理高并发业务场景!甚至很多小伙伴仍然停留在只是简单的提供接口(CRUD)阶段,不知道学习的并发知识如何运用到实际项目中,就更别提如何构建高并发系统了!
究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构,结合高并发专题下的其他文章,学以致用 。
电商系统架构在电商领域,存在着典型的秒杀业务场景,那何谓秒杀场景呢 。简单的来说就是一件商品的购买人数远远大于这件商品的库存,而且这件商品在很短的时间内就会被抢购一空 。比如每年的618、双11大促,小米新品促销等业务场景,就是典型的秒杀业务场景 。
【高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!】我们可以将电商系统的架构简化成下图所示 。
高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!

文章插图
 
由图所示,我们可以简单的将电商系统的核心层分为:负载均衡层、应用层和持久层 。接下来,我们就预估下每一层的并发量 。
  • 假如负载均衡层使用的是高性能的Nginx,则我们可以预估Nginx最大的并发度为:10W+,这里是以万为单位 。
  • 假设应用层我们使用的是Tomcat,而Tomcat的最大并发度可以预估为800左右,这里是以百为单位 。
  • 假设持久层的缓存使用的是redis,数据库使用的是MySQL,MySQL的最大并发度可以预估为1000左右,以千为单位 。Redis的最大并发度可以预估为5W左右,以万为单位 。
所以,负载均衡层、应用层和持久层各自的并发度是不同的,那么,为了提升系统的总体并发度和缓存,我们通常可以采取哪些方案呢?
(1)系统扩容
系统扩容包括垂直扩容和水平扩容,增加设备和机器配置,绝大多数的场景有效 。
(2)缓存
本地缓存或者集中式缓存,减少网络IO,基于内存读取数据 。大部分场景有效 。
(3)读写分离
采用读写分离,分而治之,增加机器的并行处理能力 。
秒杀系统的特点对于秒杀系统来说,我们可以从业务和技术两个角度来阐述其自身存在的一些特点 。
秒杀系统的业务特点这里,我们可以使用12306网站来举例,每年春运时,12306网站的访问量是非常大的,但是网站平时的访问量却是比较平缓的,也就是说,每年春运时节,12306网站的访问量会出现瞬时突增的现象 。
再比如,小米秒杀系统,在上午10点开售商品,10点前的访问量比较平缓,10点时同样会出现并发量瞬时突增的现象 。
所以,秒杀系统的流量和并发量我们可以使用下图来表示 。
高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!

文章插图
 
由图可以看出,秒杀系统的并发量存在瞬时凸峰的特点,也叫做流量突刺现象 。
我们可以将秒杀系统的特点总结如下 。
高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!

文章插图
 
(1)限时、限量、限价
在规定的时间内进行;秒杀活动中商品的数量有限;商品的价格会远远低于原来的价格,也就是说,在秒杀活动中,商品会以远远低于原来的价格出售 。
例如,秒杀活动的时间仅限于某天上午10点到10点半,商品数量只有10万件,售完为止,而且商品的价格非常低,例如:1元购等业务场景 。
限时、限量和限价可以单独存在,也可以组合存在 。
(2)活动预热
需要提前配置活动;活动还未开始时,用户可以查看活动的相关信息;秒杀活动开始前,对活动进行大力宣传 。
(3)持续时间短
购买的人数数量庞大;商品会迅速售完 。
在系统流量呈现上,就会出现一个突刺现象,此时的并发访问量是非常高的,大部分秒杀场景下,商品会在极短的时间内售完 。
秒杀系统的技术特点我们可以将秒杀系统的技术特点总结如下 。
高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!

文章插图
 
(1)瞬时并发量非常高
大量用户会在同一时间抢购商品;瞬间并发峰值非常高 。
(2)读多写少
系统中商品页的访问量巨大;商品的可购买数量非常少;库存的查询访问数量远远大于商品的购买数量 。
在商品页中往往会加入一些限流措施,例如早期的秒杀系统商品页会加入验证码来平滑前端对系统的访问流量,近期的秒杀系统商品详情页会在用户打开页面时,提示用户登录系统 。这都是对系统的访问进行限流的一些措施 。


推荐阅读