写点什么

设计电商秒杀系统

作者:AUV
  • 2022 年 3 月 26 日
  • 本文字数:1497 字

    阅读完需:约 5 分钟

【业务背景】

你作为一个电商创业公司的架构师,负责设计 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.      1000 个充电宝,10 个 iphone12,绝对不能超卖

2.      前端使用 android、ios、微信小程序

3.      后端使用 java 实现

4.      6 月 18 日之前完成

 

【总体架构】

业务架构图



系统架构图



【复杂度分析】

1.      业务复杂度



2.      质量复杂度

(1)高性能复杂度

日活 100 万用户,由于是秒杀,假设 60%用户集中在 0:00-0:15 时段下单,QPS=100*10000*60%/(15*60)=666

 

(2)高可用复杂度

秒杀活动,大量用户等待 18 日零时下单,会造成请求量瞬时大幅度上涨。

 

【详细设计】

1.      核心功能

按照业务边界,划分为三个领域:

l  核心域:商品、订单、交易,作为整个核心业务,应保证稳定、可靠。

l  支撑域:商品、订单、交易、仓储、物流、客服、店铺、会员、购物车,提供单体非核心业务能力

l  通用域:登录、个人信息、权限、余额、信用、安全,提供通用能力

2.      关键设计

(1)高性能设计

a)     采用三级负载

一级 DNS,二级 nginx,三级微服务网关。

b)    容器化部署

实时监控应用请求,可根据入口流量的增长,增加 k8s 部署的 pod 数量。

c)     动静分离

采用 CDN 将一部分静态资源缓存到用户本地,减小服务器压力。

d)    应用缓存

秒杀开始前,可将秒杀商品预加载到缓存,避免缓存穿透,并且注意错峰设置缓存过期时间,避免发生缓存雪崩。

e)     异步

除下单、支付等实时性要求较高场景,仓储、物流等实时性要求较低场景可采用消息队列等异步形式实现。

 

(2)高可用设计

a)       前端:增加节流、防抖手段,并做重复性校验,防止重复提交

b)    网关:同样增加重复性校验,增加限流策略,并通过熔断机制保护整个链路,避免引发雪崩效应

c)    组件:注册中心、缓存、微服务网关均采用集群模式,节点数量 3-5 个

d)       监控:后台通过 apm 等可视化手段做好监控与报警

e)       应用:应用采用容器化部署,k8s 单服务设置 pod 节点 3-5 个

f)     数据库:采用集群方式部署,并采用主备方式保证高可用

g)       资源分配:各类资源应优先保证核心域的正常可用

 

【设计规范】

1)采用前后分离,客户端采用 Android、IOS、微信小程序,后端使用 Spring Boot,接口采用 Restful 风格。

 

2)MySQL 使用 Innodb 存储引擎,禁止使用存储过程、触发器,数据库利用 sharding-proxy 做分库,使用 binlog 做主备同步。

 

用户头像

AUV

关注

还未添加个人签名 2021.10.24 加入

还未添加个人简介

评论

发布
暂无评论
设计电商秒杀系统_「架构实战营」_AUV_InfoQ写作平台