背景

业务场景分析

1.商品数量：20(商品) * 10(品类) = 200(商品)

2.秒杀数量：1000 个充电宝，10 台手机

3.活跃用户 100W，考虑推广加入的新用户：20W，所以 6.18 当日活跃用户 120W

秒杀流程

1.用户注册并登录到 App

2.关注秒杀商品信息

3.到达秒杀时间，参与秒杀

业务功能

注册、登录、秒杀、购物、支付

复杂度分析

高可用

1. 秒杀模块需要做到高可用，登录模块也需要做到高可用，只有登录成功后才

可以参与秒杀，在秒杀的过程中不允许服务模块挂掉

2. 支付、购物等其他模块能正常使用即可，允许出现最大 1m 服务失效

高性能

1. 秒杀模块对计算、存储都有高性能的要求，因为活跃用户有 120W，秒杀又在 3 秒内完成，估算：120W / 3s = 40W 的请求

可扩展

1. 同城双机房暂不考虑，原因：秒杀是瞬间并发大，出在故障的概率极低。

存储架构

【登录】

120W 用户登录

【秒杀】

考虑到不是所有活跃用户都参与商品秒杀，预估为：120W / 3s = 40W(约)

【购物】

由于是 618 大促，除了秒杀还有其他的正常购物通道，假设活跃用户平均每人下单两次，

即订单记录：2 * 120W= 240W，其秒杀产生的订单记录量少可以忽略统计，

且不存在数据删除的情况

【支付】

支付允许在下单一小时内完成，也考虑到下单后有不支付的情况，

支付记录：240W * 85% = 210W(约)，其秒杀产生的支持记录量少可以忽略统计

Mysql 存储架构图

采用 Mysql 主/从实现存储高可用，采用批量写入提高写入性能

存储数据量

1.用户信息 120W

2.订单记录：240W

3.支付记录：210W

索引

1. 订单记录表

A. 索引：用户 Id、订单创建时间

B. 场景：根据用户显示订单记录；运维后台根据时间段统计订单记录

2. 支付记录表

A. 索引：订单 Id、用户 Id、支付时间

B. 场景：用户订单显示支付信息；统计一段时间支付信息

Redis 存储架构图

存储数据量

1. 用户信息：120W

2. 秒杀列表：1100

3. 由于业务集群最大并发为 10W，所以 Redis 最大 TPS 也为 10w，2 台 Redis 服务器即可

数据结构设计

1. 秒杀商品缓存数据结构

A.选用简单的 Int，Key 不重复

B.Key：商品类型编号

C.Value：商品库存

D:说明

1. 接口首先根据 商品类型编号 获取库存

2. 判断 库存是否<=0，如果<=0，返回提示商品被抢完

3. 否则 通过 DECR 减库存

4. 再获取一次库存，进行第二次判断库存是否 < 0

5. 如果>=0，生成订单

2 .用户登录信息

A.选用 Hash

B.Key：用户 Id

C.Value：token 信息

计算架构

计算负载均衡

1.两台 LVS 做主从，通过 keepalive 做高可用

2.消息队列集群，单台服务 10w 消息，所以 40w /10w = 4 台   增加 2 台备用，共需要消息队列服务器 6 台

3.单台业务服务器处理能力 1000/S(秒杀逻辑并不复杂，操作 Redis)，   业务服务器集群只支持 10w / 1000 = 100 台，加上 20%的备用，所以一共需要 120 台

缓存架构

1.采用三级缓存

2.本地和 WEB 容器缓存，主要缓存静态资源和一些少变化的数据，如：商品信息，商品照片等

3.分布式缓存主要缓存秒杀库存信息、用户登录信息等

可扩展架构

微服务拆分

1. 秒杀服务

2. 综合服务增加如下模块

3. 秒杀商品库存缓存初始化服务

4. 其他复用现有服务

整体架构