架构实战营|模块 9

一、性能估算

1、根据业务背景分析，正常的日活大越 100 万用户，秒杀活动日活会远大于平时，按 5 倍预计，即日活 500 万用户。

2、本次秒杀是为了促进用户转化为 APP 用户，所有参与用户下载 APP，这里会涉及到原小程序用户的转移和少部分新注册用户且只需下载 1 次客户端即可，对现有系统不会造成太大影响。

3、秒杀活动商品是 1000 个充电宝和 10 台手机，数据库事务处理量小，不需要过多的数据库设计。

4、秒杀活动基本在几秒内完成，这里假设在 10 秒内完成，假设 500 万用户在 10s 内都进行了秒杀操作，则秒杀的 QPS 是 30 万/s。

二、架构设计

1、存储架构设计

根据性能分析，秒杀商品的数量很少，只需使用 mysql 进行数据存储即可，考虑到数据库的高可用，使用 mysql 主备模式即可。

2、计算架构设计

技术团队以 Java 为主，已经落地了微服务架构，所以可以将秒杀单独出来作为一个微服务进行部署，可以较少对其他服务的影响。

秒杀系统短时间内容会有大量的请求，所以需要多台服务器进行负载均衡，服务器内部可以使用消息队列进行处理，以最先的 1000 多个请求作为实际消费者，获取订单信息。

3、缓存架构设计

一般用户会在秒杀活动开始前提前进入到应用中的秒杀页面，假设 500 万用户提前 1 分钟进入页面，QPS 为 500 万/60s=8 万/s，redis 的处理性能在 10 万/s，所以这里使用 redis 做缓存即可。

4、高可用架构设计

目前只有单机房，不具备多机房的条件，只能做好应用的高可用，使用多个应用服务集群，数据库使用主备，redis 使用集群模式，保证了简单的高可用。

5、可扩展架构设计

秒杀服务使用微服务，本身具备良好的扩展性，通过负载均衡进行水平扩展。

6、最终架构方案

7、架构演进

在后续商品规模上来后进行多机房的部署，提升高可用性。在用户规模和流量上来后需要考虑加入业务操作限流，是整个系统保持良好运行状态。