架构实战营第九模块作业 - 毕业项目

一、业务基本场景

1.下载(只有下载 App 才能参加秒杀活动。

2.注册(促进用户转化为 App 用户)。

3.登录(促进用户转化为 App 用户)。

4.浏览商品。

5.秒杀。

6.支付。

二、总体架构思路

1.  秒杀业务是临时活动，为了避免影响正常业务的功能和复杂度，需要独立秒杀微服务。

2.  资源动静分离，静态资源上传到 CDN 中，减少对服务器的请求数量。

3.  在客户端和微服务实施请求限流。

4.  使用 redis list 来存储秒杀商品数目，一种商品对应一个 list。

三、存储架构

1. 除新增业务外，其余业务不会超过原来规定的量级，忽略不计。

2. 新增内容有订单数据和商品信息，但实际量级都很小，使用 mysql 主备存储订单数据，用 redis cluster 存储商品信息。

四、计算性能估算

下载、注册、登录复用原来的逻辑，与以前相比不会有太大波动

秒杀性能估算：

假设用户在 10 秒内完成秒杀：

写入：根据分析最终只会有 1010 个订单，即 TPS = 101/s；

读取：按二八定律，假设 20%的用户，即 100W 人参与秒杀。这 100W 人在秒杀 10 秒之内完成请求，QPS：10w/s。但实际只有 1010 个名额，在终端和后台排队前进行限流，让 1010 人进入排队模块即可。QPS = [101/s , 1K/s]。

缓存架构：

用户会提前进入应用，假设这 100W 用户提前 1 分钟进入，等待秒杀开始。

QPS：100W/3600s ≈ 280/s；

综上，不涉及特别高的性能，mysql 和 redis 即可满足。

计算架构之负载均衡

计算架构之缓存架构

五、可扩展架构设计

微服务：

因为团队落地了微服务架构了，并且秒杀业务对于电商来说，是一个比较常用的功能，独立出秒杀微服务，能够避免影响原业务的稳定性。

六、详细设计

复杂度分析：主要体现在秒杀活动中的瞬时高峰请求，对于高峰请求进行限流和排队处理。

一、限流

       1、终端限流：100W 用户，app 根据随机数控制请求是否进入后台

       2、队列限流：当 redis 队列长度为 0，直接拒绝请求

对于秒杀场景来说，一个订单只能包含一个商品，这里我们为每个秒杀商品提供一个单独的队列，这样就可以分散数据在 Redis 中的存取，多个队列可以提供更好的性能。

关于队列长度，为了保证用户能够买到商品，我们并不是把所有前台的下单请求都会放到队列里，而是根据参与活动的秒杀商品数量，按照 1:1 的比例，设置队列初始长度，这样就保证了进入队列的请求最终都能生成订单。这个可用队列长度会随着预订单进入队列，不断地减少，当数值变为 0 时，下单前台会拒绝接受新请求进入队列，直接反馈用户下单失败。

当然，如果后台订单生成异常或用户取消订单后，可用队列长度会增加，前台会重新开放预订单进入队列。也可以忽略掉这些失败的订单，允许部分商品没秒完。

七、架构演进

增加运营系统，配置商品类型、数量，动态设置通过客户端的到达排队模块的请求量/商品数量的比例。