1. 业务背景

担任电商公司的架构，现有的业务模式如下:

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

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

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

4. 老板要求万无一失。

现在需要负责设计 6.18 大促秒杀系统设计。

2. 约束和限制

性能预估

用户量预估：日活 100W，假设会有 50%的人参与秒杀活动就是 50W

用户行为建模：

假如 50%的用户是在最后 10 秒才浏览秒杀页面,页面访问 QPS 约为 50W*50%/10≈2.5W：

安全限制：

防止流量过大冲击服务， 采用前端页面，客户端，5s 秒同一个用户账户只能提交一次秒杀按钮，秒杀成功用户不可再次秒杀

临时租用一个机房（成本较低，活动结束数据可迁移），防止单机房不可用

3. 总体架构

3.1 架构分析

存储架构

订单存储采用分库分表+mysql 主备的方式

库存存储采用 redis（主从）+分库分表+mysql 主备，通过 MQ 异步写哭，提高性能

负载均衡

假设临时机房与老机房的性能相差不大，每一个机房可以抗所有流量的 80%

对订单号进行取模路由新老机房，待活动结束，将数据迁移至自己的机房。

高可用

redis 使用 sentinel 保证高可用

服务管理使用 ZK，保证服务挂掉顺时切换

可扩展

采用的是微服务架构，服务器可以随便部署扩容