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. 整体架构设计