一、系统概述

1.1 业务场景

1.1.1 购物场景

用户注册登录-->浏览商品信息-->添加购物车-->下单-->支付-->物流配送-->确认收货

1.1.2 秒杀场景

用户注册登录-->浏览商品信息-->秒杀下单-->支付-->物流配送-->确认收货

1.1.3 秒杀场景时序图

1.2 复杂度分析

收集各大电商平台好评与热卖商品，10 个品类，每个品类不超过 20 个商品，则在售商品总数量 200 左右，可以使用关系型数据库进行存储；

日活用户 100 万，按照 50%比例计算，则用户总数在 500 万左右；6.18 大促期间，活跃用户数按照 40%比例增加，则大促期间日活用户数在 200 万左右；

秒杀商品，价格诱人，会有比较多的用户参与活动，假设参与秒杀活动用户数比例在 30%，则整体参与秒杀活动用户数在 60 万左右，这个数值代表 6.18 期间最大的并发访问数值；如果按照 4:6 比例分配到充电宝、iPhone 12 两个商品，再拆分到 10:00，15:00，20:00 不同的秒杀时间段，那这个并发数值会被进一步缩小，预估单个商品每个秒杀时间段的并发访问数在 30 万-40 万；

支付采用对接第三方平台，微信、支付宝，保证接收第三方推送的支付结果即可；

商品信息涉及大量图片、视频文件，使用 OSS 存储，通过 CDN 进行加速访问；

充电宝 1000 个，iPhone 12 10 台，则秒杀订单总数量 1010 条；加 6.18 大促期间每日成交量 20 万，则秒杀订单对整体的订单影响量不大；

二、架构设计

2.1 存储设计

2.1.1 库存设计

涉及秒杀场景，并发访问量较大，每次对数据库查询性能扛不住，需要在秒杀开启前将秒杀商品库存加载到 Redis 中，同时利用 Redis 单线程高性能的能力，实现秒杀扣库存。

考虑到单节点 Redis 的能力在 50000 左右，可以采用 RedisCluster 模式，8 节点类型，每个主节点配备两个从节点；同时在库存 key 的设计上也要保证均衡的落到 8 个节点上，架构图如下：

2.1.2 用户数据、商品数据

通过前面的场景与复杂度分析，用户数据 500 万，商品数量 200 个，统计上历史商品数据，按照百万计算，用户数据、商品数据可以使用关系型数据库存储，MySQL 即可，采用主从架构，架构图如下：

2.1.3 订单数据

日活 100 万，按照 20%的订单转换率，则每日有 20 万的订单，一年下来有接近 7000 万的订单，此时采用单库单表存储性能肯定受到影响，建议订单数据基于用户 ID 采用分库分表架构，架构设计图如下：

2.1.4 其它数据

图片、视频使用 OSS 进行存储，可以采用公有云的方案进行，然后配备 CDN 进行加速；

订单数据量较大，运营系统、管理后台，可以通过 ElasticSearch 进行存储，提升运营响应速度；

2.2 性能设计

秒杀场景 30 万以上的并发访问，同时领导要求万无一失，考虑 F5 的价格，决定采用 LVS 进行负载均衡的支撑，同时采用同城双机房的方式进行部署，架构图如下：

2.3 缓存设计

缓存设计采用 App 缓存、CDN、Web 容器缓存、分布式缓存，利用 CDN 存储加速商品介绍信息中的图片、视频文件的访问，提升静态资源加载速度；利用分布式缓存，减少对数据库访问的直接访问，降低数据库压力；

2.4 可用设计

搭建同城双机房架构，保证 6.18 大促的稳定运行，同时利用双机房架构，给到秒杀系统做故障切换，保证秒杀活动的万无一失。架构图如下：