毕业设计 - 设计电商秒杀系统
1.背景知识
1.1 业务背景
你作为一个电商创业公司的架构师,负责设计 6.18 大促秒杀系统的设计,你们的业务模式如下:
你们挑选选品各大电商平台上畅销和好评的商品进行销售,每个品类不超过 20 个商品,目前做了 10 个品类;
本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone 12 作为秒杀商品;
正常的日活大约 100 万
老板要求万无一失
1.2 技术背景
技术团队以 Java 为主,已经落地了微服务架构;
主要渠道是自有的 App(包括 iOS 和 Android)和微信小程序,为了促进用户转化为 App 用户,只有下载 App 才能参加秒杀活动;
目前只有单机房
2.业务背景分析
秒杀业务流程图
参考材料:【手把手带你搭建秒杀系统-佘志东】
复杂度分析
高可用:在秒杀过程中,不能因为高并发查询导致数据库宕机或者数据不一致
高性能:在进行秒杀过程中,应该及时返回秒杀结果,不能因为高并发导致用户体验差;同时,秒杀成功的商品应该可以快速进行下单支付
设计思路
针对高并发流程,要提前预防限流、快速失败,不能让其直接打到后端服务器
针对高并发读和写的场景,需要采用 Redis 集群保证数据的一致性
秒杀系统与正常的电商业务系统,独立开发部署,避免秒杀场景对整体业务产生影响
性能分析
由于该 APP 平常日均活跃大约 100 万,假设在秒杀期间 100 万用户中 60%的用户会参与秒杀,即 60 万用户
60 万用户会在秒杀前 5 分钟,进入秒杀页面查询商品详情,并在秒杀开启时进行下单,则由此可以推算出查询商品详情的 QPS 大约为:2000/s
预计在秒杀开始后 10 秒内秒杀商品(1000 个充电宝+10 个 iPhone12)全部售罄,则可估算下单的 TPS:100/s
3.存储架构
由于本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone 12 作为秒杀商品;只会产生总订单量为 1010 个,所以采用 MySQL 主备架构进行存储即可,当主机出现宕机时,可以迅速切换为备机,防止服务不可用
在秒杀准备时,需要将秒杀商品详情信息和库存上架信息存储在 MySQL 数据库中;在秒杀活动开始前期,将商品详情以及库存信息缓存到 Redis 集群中;
根据上述分析,QPS 为 2000/s,采用 Redis 集群即可抗住读压力
依据 Redis 的单线程特性,可以通过内嵌 Lua 脚本判断并进行库存扣减
对象存储,用来存储商品图片
4.计算架构
4.1 计算架构之负载均衡
防刷单:由于在秒杀期间,存在机器刷单情况,可以在 Nginx 层进行控制,若某用户 ID 在近 30s 内,访问次数超过一定次数,则直接返回“亲,您未抢 XX,请再接再厉!”
设置服务实例个数:根据第二章节分析可知,真正促成下单的 TPS:100/s,假设秒杀服务的 TPS 为 100/s,则这里部署三个实例(做冗余,防止服务不可用)
路由 Hash:服务网关根据商品 ID(提前将上架商品进行一一编号)通过 Hash 的方式路由到指定的服务实例
4.2 计算架构之 5 级缓存
采用 5 级缓存架构,在秒杀活动开始前,可以根据通过预热的方式,将商品信息缓存在 App 上
将商品图片信息缓存到 CDN 上,可以就近拉取数据
分布式缓存用来存储商品库存信息以及商品详情
4.3 计算架构之接口高可用
根据上述的流程图和负载均衡架构,我们可以每一层做限流处理,防止突发流量将系统压垮
针对秒杀订单的处理过程,我们采用排队机制,来对突发流量做整形,具体流程如下:
5.疑问
上针对秒杀系统做了存储架构和计算架构的分析,其中针对 QPS 和 TPS 的估算是否准确,需要老师能够指导一下
版权声明: 本文为 InfoQ 作者【默光】的原创文章。
原文链接:【http://xie.infoq.cn/article/afe12eba02adc7c4105ff9a18】。文章转载请联系作者。
评论