业务基本场景分析

1. 将业务抽象为如上图所示的三个步骤；

2. 登陆：由于有活动的影响，估计为平均日活的 5 倍，当天首次登陆集中在活动开始前 30 分钟，包含当天流量的 50%，TPS = 100w x 5 x 50% / 30min = 1400

3. 查看商品：由于有 APP 本地缓存与 CDN 缓存，在加上品类和商品数量较少，对后端数据库的压力可以忽略；

4. 秒杀：假设有 30%有用户参与秒杀，借由 APP 本地随机过滤 90% 用户，以及微服务限流策略 1w qps，TPS = 1w；

5. 订单：秒杀订单峰值 1000 tps 订单存储；

6. 老板要求万无一失：之前又是单机房架构，所以选用同城双机房架构，将双中心作为一个中心使用；

微服务模块划分

将业务分为上图所示的 4 个模块

1. 由于秒杀服务与一般的商品服务不通，将其拆分为独立模块；

2. 其他均以业务进行划分；

存储架构

1. 考虑 1w qps 的秒杀请求，以及同城双中心，采用 redis cluster 做为存储的商品和订单的缓存；

2. 考虑 1k qps 的写入，采用双 mysql 集群，业务进行订单的双写，保证 sla；

计算架构

负载均衡架构

1. 为了应对 1w qps 的请求量，使用 LVS 集群 -- 服务网关集群 -- 业务集群的三级负载均衡架构

缓存架构

1. 使用 APP 缓存 -- WEB 容器缓存 -- 分布式缓存的三级缓存架构

高可用架构

1. 选用同城双机房架构，将双中心作为一个中心使用；

2. 由于数据库选用 mysql 无法保证单中心故障场景下的写入能力，所以修改业务为双写