毕业设计

一、性能估算

业务模块 ：

商品查询>抢购>抢购结果查询

1、存储性能估算

秒杀参与用户：按日活的 3 倍来估算，100W*3=300W；

抢购记录：本次参与秒杀的有 2 种商品，假设每种商品用户都参与抢购，

则抢购记录为 300W*2 = 600W，假设每条记录大小为 20KB，则 600W*20KB=114G；

2、计算性能估算

2.1、商品查询：假设抢购活动开始前后 5 分钟内参与抢购的用户每人查询 10 次商品，

则 QPS 为：300W*10 / 5 分钟 / 60 秒 = 10W;

2.2、抢购：秒杀活动开始后 5 分钟内商品即被抢光，

则 TPS 为：300W / 5 分钟 / 60 秒 =1W；

2.3、抢购结果查询：假设抢购活动结束后 5 分钟内参与抢购的用户每人查询结果 2 次，

则 QPS 为：300W*2 / 5 分钟 / 60 秒 = 2W；

二、存储架构设计

1、活动日数据量预估为 114G，单机 Mysql 能够支持存储，但无法支撑抢购活动的读、写压力，读写操作都

基于 Redis，因 QPS 达到 10W，接近单机最大负载了，需要使用 Redis 分片集群。

2、对于抢购操作先写到 MQ 中，由批处理应用来消费 MQ 消息并处理抢购逻辑，以达到瞬时计算和写压力，批处理应用处理完抢购逻辑后把结果同步写入 Redis 和 Mysql，Mysql 用于抢购记录和抢购结果持久存储；

三、负载均衡架构

TPS 最高 1W，QPS 最高 10W，单台 Nginx 性能就能满足

四、缓存架构设计

系统使用 4 级缓存，为尽可能减轻抢购活动的瞬时流量对系统的压力，且老板要求万无一失，增加 CDN 缓存，商品图片等静态资源都提前更新到 CDN 上；

五、可扩展架构设计

1、为避免秒杀影响电商系统和周边其他系统，需要把秒杀拆分出来作为一个独立的服务，隔离秒杀对其他服务的影响；

2、秒杀核心功能拆分为：商品查询、抢购、抢购结果查询，考虑的商品查询的 QPS 最高，把这商品单独拆分为一个服务，抢购及抢购结果查询相关性比较高，这 2 个模块合并为一个服务。

综上，拆为如下两个服务：

六、高可用架构设计