架构实战营 第 6 期 毕业设计

1. 毕业设计项目

2. 估算

根据正常日活100万用户，为确保万无一失，假设活动时吸引平时10倍的用户，则有大约

1000万用户

在线。

假设秒杀活动的读写请求最高峰会出现在活动开始的时间点前后大约

5秒

的时间。

则可推测

QPS：1000万/5s = 2000K/s

TPS：1000万/5s = 2000K/s

3. 存储架构

目前正常业务的商品大约10个品类 x 20个商品 = 200个商品。

参与秒杀的商品只有iphone和充电宝2个。

考虑使用已有的数据库框架，假设是

MySQL主备

。

为了不影响正常业务，可为秒杀活动新建

单独的数据库

。

4. 计算架构

因为已落地了微服务架构，考虑将秒杀活动的业务作为

独立的微服务

加入到服务集群中。以免影响正常的业务逻辑。

虽然估算的QPS和TPS很高，但是秒杀的商品一共只有1000多个。也就是说前1000多个请求成功之后，后面的请求都根本不需要处理了。

假设一台业务服务器的处理能力是1000/s，一台服务2秒内就能处理完。为了万无一失，建议配备

至少3台业务服务器。

4.1 缓存

假设已有

Redis分布式缓存架构

，可将参与秒杀的商品信息写入缓存，读取请求直接读取缓存即可。

4.2 负载均衡

对于写入请求，由于秒杀本来就会有大量请求失败。在app应用端，可以进行一次过滤。例如，

随机将50%的请求直接忽略

，并在客户端显示繁忙的信息。

服务器端，假设已有

2台Nginx负载均衡

。

另外在服务器端使用

漏桶算法

。已知发团队使用Java，可以使用

BlockingQueue

。桶的大小可以设为比秒杀商品的总数大一点。

比如，配置3台秒杀业务的服务器，每台服务器的漏桶大小设为400。则两台服务器一共可以保证1200个请求得到处理。其他请求则可以直接返回失败。

5. 高可用与可扩展

虽然目前只有单机房，老板要求万无一失，但是秒杀活动应该在几秒之内就结束了。

无需考虑额外的高可用

。

秒杀活动为一次性的业务，

不用过多考虑可扩展

。将秒杀的业务作为独立的微服务即可。

6. 整体架构设计