【业务背景】

1. 你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下:1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类;

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

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

4. 老板要求万无一失。

【模型性能估算】

【浏览、购买】

日活 100w，在线浏览与购买最高 QPS 约 40%，即 40w，订单转化率约 5%，即 5w；

【秒杀】

秒杀：1000 充电宝、10 台 iphone 都为整点抢，预计在线抢购超过 50%，qps 为 50w

【订单】

100w 日活用户，约 200 个品类商品，预计每个活跃用户购买 10 个订单超 1000w 订单数据；

【系统特点】

高性能：秒杀涉及大量的并发读写，需要支持高并发访问，因此可以将秒杀库存存 redis，同时通过 app 进行“秒杀预约”对缓存预热，预估秒杀 qps。

一致性：秒杀商品减库存，需要保证数据一致性，有限数量商品在同一时刻被多倍请求同时减库存，在大并发更新过程中需要保证数据的准确性。

高可用：秒杀时会在一瞬间涌入大量流量，为了避免系统宕机，保证高可用，需要做好流量限制

【存储架构设计】

Mysql 存储

用户信息：日活百万，注册用户可能是千万级别，因为存在客户信息获取等大量查询，可以对用户表按 id 后两位 hash 进行分库分表；

商品信息：单表

订单信息：超千万历史订单记录，每天写 db 超 w，可以按订单 id hash 分库分表

秒杀订单：持续时间短，瞬时量大，可以建立单独库表存储

Redis 存储

秒杀预热：可以把相关商品信息、预约用户 id 暂存 redis，存储量不超过单机存储，因此可以用单实例；

秒杀库存可以在 redis 里用分布式锁保证库存扣减，为保证高可用，可以用哨兵模式实现主从复制、读写分离、并保证故障主从自动切换

【计算架构设计】

负载均衡

因为日活用户百万，秒杀 qps 最高可百万级别，考虑到后期业务增量，可以在网络侧加一层 LVS 做流量负载均衡，同时在业务服务器增加接入网关层，专门负责秒杀的限流、降级；以及条件校验和流量过滤

缓存

客户端缓存：秒杀预约时，缓存商品信息、客户资格、订单信息等、秒杀倒计时等；

CDN 缓存：缓存秒杀 html、js 等文件

分布式缓存：缓存秒杀商品信息、客户信息等，提升访问速度

【可扩展架构设计】

微服务

秒杀模块分为：接入代理层、库存管理服务、秒杀订单三个微服务，分别和已有的用户、商品、交易、订单服务交互

【高可用】

同城灾备：因为要起里是单机房，考虑到成本，因此无法做双活，或同城灾备