架构实战营 模块九 作业

业务基本场景

登录 >>> 浏览商品>>>下单>>>支付

分析

• 秒杀活动的瞬时流量很高，需要使用缓存降低后端压力。

• 日活用户 100 万，假设在秒杀活动期间会有 3 倍的用户参与，架构设计按着百万级进行设计

• 秒杀活动的商品库存需要和常规库存分开，可以使用 Redis 存储秒杀商品库存

• 当前架构中已经落地微服务，可把秒杀活动单独设计成为一个微服务

• 登录：日活用户 100 万人，因为秒杀活动增加了活跃用户，假设当天会有 100 万到 120 万参加活动，用户会在开始前半小时登录, qps: 120 万/1800s 约等于 667

• 秒杀活动：假设用户会在活动开始前 10 秒开始频繁访问秒杀商品页面，qps 约为：10 万~12 万，tps 约为：10 万~12 万

• 秒杀活动开始后 2 秒内用户进行下单操作：qps 约为：50 万~60 万，tps 约为：50 万~60 万

• 只有 app 端才能参与秒杀活动

负载均衡设计

• 登录：日活用户 100 万人，因为秒杀活动增加了活跃用户，假设当天会有 100 万到 120 万参加活动，用户会在开始前半小时登录, qps: 120 万/1800s 约等于 667

• 秒杀活动：假设用户会在活动开始前 10 秒开始频繁访问秒杀商品页面，qps 约为：10 万~12 万，tps 约为：10 万~12 万

• 秒杀活动开始后 2 秒内用户进行下单操作：qps 约为：50 万~60 万，tps 约为：50 万~60 万

• QPS+TPS 已经到了百万万级，采用 4 级负载均衡架构

缓存设计

采用三级缓存架构，秒杀商品信息存储在 Redis 中，分布式缓存可以使用 Redis 主从，采用哨兵模式

存储架构设计

• 登录：活跃用户在 100 万~120 万，可以使用 mysql 存储登录信息

• 秒杀商品：需要频繁查询库存信息，所以使用 Redis 存储活动库存，同日常售卖库存隔离，Redis 单机 TPS 为 5~10 万，使用 Redis Cluster

• 订单：假设秒杀活动带来了 20%购买转化率，订单量为 20 万~40 万，存储在 mysql 即可

高可用设计

老板要求万无一失

• 为防止活动进行中流量突增，需要增加部分机器进行备用。

• 目前只有单机房，可考虑进行同城双机房灾备方案，防止出现机房级别的故障导致服务宕机

可扩展设计

百万用户级别的业务，可以把秒杀活动单独拆分成为一个微服务进行设计，方便后续进行维护升级