毕业设计要求

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

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

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

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

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

设计电商秒杀系统

性能预估

1. 日活 100 万用户，参与秒杀的用户按照日活的 5 倍进行计算，大约为 500 万

秒杀场景分析

1. 浏览商品（刷新商品详情）：用户在秒杀前 1 分钟内和秒杀中会频繁的刷新商品详情，对商品信息在 App 端进行缓存，用户刷新秒杀商品详情，只获取秒杀相关信息，同时服务端提前对秒杀商品进行预热，写入缓存防止缓存雪崩

2. 秒杀商品：大量用户在同一时间内 对同一商品进行下单， 为避免秒杀的大流量导致其他用户无法正常购物，需要将秒杀作为单独服务部署， 由于秒杀商品商品数量有限，采用漏桶算法对请求过滤

3. 秒杀商品减库存： 采用下单减库存，通过缓存减库存，当减后库存大于等于 0，则允许下单。支付通过排队 对实际的支付请求进行限流（最高并发 1000TPS）,支付时进行实际库存扣减，如果库存不足则不允许支付

4. 库存设计：a. 缓存存储库存信息，用于秒杀时校验是否允许下单

   b. 数据库中实际商品的库存信息，用于商品下单时校验商品库存余额

存储架构设计

存储性能评估

浏览商品：本次秒杀总共两件商品，商品信息提前缓存至 CDN 及分布式缓存服务中，缓存命中率 100%，不存在缓存穿透的情况，并无存储的压力

秒杀商品：有两部分组成 1. 商品库存缓存 2. 商品订单

1. 商品库存缓存 ， 本次秒杀总共有 2 种商品参与，所有对于的缓存数量只有 2 条

2. 商品订单：实际订单数就是商品总数，本次秒杀总共会生成 1010 条订单

存储架构设计

使用 MySQL 存储商品订单数据，采用 MySQL 主备

对于秒杀商品：存储 1010 条订单信息

Redis 缓存存储商品信息以及库存信息，采用主从复制

对于秒杀商品：2 件秒杀商品信息，2 条秒杀商品库存信息，50 万缓存读操作

计算架构设计

计算性能评估

浏览商品：本次秒杀总共两件商品，商品信息提前缓存至 CDN 及分布式缓存服务中，缓存命中率 100%，不存在缓存穿透的情况，并无存储的压力

秒杀商品：秒杀商品分两部分 1. 下单校验 库存是否充足 2. 商品支付 生成订单同时用户对商品进行付款

对于 下单校验：通过 App 端限流允许 5%的请求访问服务端，大约为 25 万 QPS，下单会校验库存是否充足，而库存量保存在缓存中，所以缓存对应的 QPS 也是 25 万

对于 商品支付：实际订单数就是商品总数，本次秒杀总共会生成 1010 条订单，对于的订单 TPS 为 1010TPS

负载均衡

无需异地多活，因为实际商品只有 1000 件，而且是秒杀场景不允许出现超售情况，为避免同步延迟导致的数据不一致，所以不考虑做异地多活

对于老板要求的万无一失，可以考虑消除单点问题，保证服务高可用，做好服务的熔断和限流，如果秒杀的请求过大，可以限制对应的秒杀接口；同时将秒杀服务单独部署，与正常业务相互独立，防止秒杀服务异常导致

缓存架构

针对秒杀系统，主要依靠缓存服务来拦截大部分请求，包括 商品展示信息、秒杀相关信息，商品库存信息等，而且缓存服务一般都支持高并发访问,避免对数据库造成压力