架构实战营 - 第 6 期 模块九之毕业设计

毕业设计项目

架构设计如下：

一、性能估算

1、根据业务背景分析，普通正常日活大约为 100 万用户，鉴于秒杀活动优惠较大，秒杀当天的活跃用户数会增加，假设增加的用户数是平常的 3 倍，为了满足老板万无一失的要求，假设秒杀当天所有用户都参与秒杀，则秒杀的用户数为 300 万。通常情况下，秒杀活动都是在很短时间内完成，因为不同手机设备和网络状态，以及用户的操作手速不同，假设所有的秒杀请求是在 10 秒内完成。

则：秒杀 QPS = 300 万 / 10 = 30 万/s

2、因为秒杀的总商品数量有限，总共才 1000 个充电宝加 10 台手机，所以真正需要达到数据库的事务处理最多也就不到 2000 左右，故 TPS 很低，可以不用做额外性能分析。

二、存储架构设计

1、根据业务背景分析，当前电商平台总共 10 个品类，每个品类不超过 20 个商品，最多总共也只有 200 个商品，所以一个 mysql 实例即可满足，鉴于要实现数据库的高可用，单实例宕机不影响业务进行，所以选择 Mysql 主备模式即可。

三、计算架构设计--负载均衡

1、根据技术背景分析，团队已 Java 为主，已经落地了微服务架构，那么秒杀作为一个常见，特殊，且对性能要求较高的模块，完全可以单独拆分出来，作为一个独立的微服务部署，这样可以提高扩展性，减少高并发的秒杀场景的下，对普通业务请求的影响。

2、秒杀意味着短时间内大量请求过来，所以需要多台服务器来接收和相应请求，所以需要选择 Nginx 做负载均衡，一台正常的 Nginx 的并发能力，大约在 3 万左右，据此计算，我们需要 10 台左右的 Nginx 服务器。但是鉴于真正参与秒杀的商品，只有 1010 个商品，所以超过这个数量的大量请求，进入到后端也是没有实际意义的。但是为了秒杀系统的稳定性，以及不出现单点故障，故选择两台 Nginx 服务做负载均衡。

3、业务服务器的话，根据以上分析计算，假设一台业务服务器的并发能力为 1000，那么两台服务器就完全满足业务需要，为了做到万无一失，可以在增加一台服务器，做备份和故障转移使用。还可以再准备两台服务器，做异步任务处理，所以秒杀的业务服务器准备 5 台即可。

四、缓存架构设计

1、首先参与秒杀的商品，会在短时间内被查看，所以可以采用 App 本地缓存，提前加载需要秒杀的商品信息。

2、还可以使用 CDN 缓存，提前把商品信息预热加载到各个地区的 CDN 节点，让用户可以就近访问到秒杀的商品信息。

3、商品的一些关键的信息，比如商品数量，价格等，可以使用 Redis 缓存数据库，不用每次查询都走数据库，使响应请求更加快速高效。因为参加秒杀的商品总数并不多，所以使用 Redis 主从模式即可，为了实现高可用，还可以使用 Redis 的哨兵模式，做到故障自动转移，实现缓存高可用。

五、对请求进行削峰的设计--消息队列

秒杀场景下，短时间内大量请求过来，为了不把业务服务器，以及后边的缓存，数据库等服务器压垮，也可以选择使用消息队列的方式，对请求进行削峰，把请求平滑的放进消息队列，然后快速返回给用户已经参与秒杀，秒杀结果，请耐心等待。然后后台再开启一些消费者服务器，根据服务器的处理能力，平滑稳健的消费和处理每个请求，通过消息队列的使用和异步任务处理，让系统更加健壮和可靠。

六、高可用架构设计

1、数据库，缓存的高可用，已经在上面文案有所体现，不再赘述。

2、由于目前之后又单机房的条件，不再多异地多活和同城多活等高可用，只需要做好单机放内的业务，缓存，数据库服务器的高可用即可。

七、可扩展架构设计

1、由于秒杀服务已经是微服务，所以需要扩展的话，做好秒杀项目微服务的负载均衡，水平扩展即可。

八、最终架构设计