写点什么

架构实战营 - 毕业设计

用户头像
莫问
关注
发布于: 2 小时前

题目

毕业设计:设计电商秒杀系统

【业务背景】你作为一个电商创业公司的架构师,负责设计 6.18 大促秒杀系统的设计,你们的业务模式如下:1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售,每个品类不超过 20 个商品,目前做了 10 个品类;2. 本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone12 作为秒杀商品;3. 正常的日活大约 100 万用户;4. 老板要求万无一失。

【技术背景】1. 技术团队以 Java 为主,已经落地了微服务架构;2. 主要渠道是自有的 App(包括 iOS 和 Android)和微信小程序,为了促进用户转化为 App 用户,只有下载 App 才能参加秒杀活动;3. 目前只有单机房。

【毕设要求】1. 设计完整的架构,例如存储、负载均衡、缓存、高可用、可扩展等;2. 大约 10 页以内的 PPT,每页 PPT 说明一项设计,包括架构设计和设计理由,无需详细解释备选方案。

【提示】1. 分析考虑要全面,但并不意味着架构设计要面面俱到,如果分析后认为某些设计点可以不做,就在作业最后统一说明原因即可;2. 如果没有思路,请对照模块 9 的 IM 案例。3. 如果有的信息觉得不够全或者不够细,可以做出一定的假设,但不能天马行空,需要对照已有的业务背景和技术背景进行合理推断。

思路

业务背景

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售,每个品类不超过 20 个商品,目前做了 10 个品类;

2. 本次 6.18 秒杀选择了 1000 个充电宝,10 台 iPhone12 作为秒杀商品;

3. 正常的日活大约 100 万用户;

4. 老板要求万无一失。

总体架构思路

  1. 正常日活用户 100 万用户,大概有 60%~120%的用户会参与秒杀活动,所以架构按照百万用户级别参与秒杀设计,适应最大业务需求。

  2. 客户端只有下载 App 才能参加秒杀活动,所以架构设计只考虑 App 的情况。

  3. 秒杀活动不经常有,保持单机房不变。

存储架构思路

存储架构估算

  • 登录

正常日活用户 100 万,登录数据是每天 100 万

  • 浏览秒杀商品

100 万用户同时浏览两种商品,1000 个充电宝和 10 台 iPhone12。

  • 下单

1000 个充电宝和 10 台 iPhone12,订单数量 1

存储架构设计


  • 秒杀开始时,为了支撑大量高并发的商品库存查询,用 Redis Cluster 支持。

  • 商品库存扣减和订单操作数据量不大,仍然有 MySQL 支持。

计算架构思路

计算性能估算

  • 登录

估计有 60~120 万用户登录,考虑到 50%用户可能会集中在秒杀时间前 1 个小时登录,登录的 TPS 值:

50 万/3600 ≈ 140

  • 秒杀

估计有 60~120 万用户会在前 2 秒内参与秒杀,绝大部分是读请求。秒杀的 QPS 值:30 万~60 万

计算架构之负载均衡

  • 考虑到 QPS 在 30 万~60 万,采用 LVS 作负载均衡设计

计算架构之缓存架构

  • 尽量把商品详情页的页面元素静态化,然后使用 CDN 或 App 把这些静态化的元素缓存起来。秒杀前大量请求可以直接由 CDN 或 App 缓存服务,不会到达服务器端,减轻服务器端压力。

  • 秒杀活动开始,为了支撑大量高并发的库存查验请求,由 Redis 保存库存,扣减库存。yin'ci 分布式缓存也选用 Redis。

其他架构设计

高可用

秒杀系统在大流量的冲击下,容易出现意外情况,为了保证系统的高可用,要有相应的保护措施。

  • 高可用-排队

  • 收到秒杀请求后并不是立即处理,而是放到消息队列,系统根据能力进行异步处理。

  • 队列的大小根据秒杀商品数量或多一些定义。

  • 相比较限流来说,排队的客户端体验要更好一些。

发布于: 2 小时前阅读数: 5
用户头像

莫问

关注

站在现在看未来,站在未来看现在 2019.11.20 加入

居安思危,先忧后乐

评论

发布
暂无评论
架构实战营-毕业设计