一、需求分析

1.10 个品类不超过 20 个商品，也就是 200 个商品。

2.日活用户大约 100W，可以推断在秒杀活动期间，至少会有 3~5 倍的用户参与，架构设计至少参照千万级别架构设计；

3.秒杀活动的并发量很高，需要用缓存降低后端压力，故存储方面采用 mysql 和 redis；

4.老板要求万无一失，代表系统有较高的容灾和高可用要求；

5.团队已经落地微服务，而秒杀活动的交易并发量很高，故需要单独开发和部署秒杀服务。

6.创业型公司且技术人员不会太多，作为业务重点的秒杀活动，可用根据需求安排 12 个人做后端、andorid3 个、ios3 个。

二、业务流图

用户的主要业务流程包括，下载 APP，然后注册/登录；打开首页，查看推荐商品和秒杀商品；抢购商品，抢购时支付前先查询库存，支付后库存自动减 1；最后系统记录用户的购物信息。

三、计算架构设计

1.注册登录

TPS: 日活用户 100 万人，假定活动当天新增 10 倍用户，一共 1000 万用户，80%登录注册发生在 5 小时内，则 TPS=1000 万*0.8/5/3600=450

2.热销商品

QPS:10 大类，每类 20 个商品，一共 200 个商品。当天一共 5 倍的人查看，每人查看 3 次，每次查看 5 个商品，且 80%的请求发生在 5 小时内，则 QPS=500 万*3*5*0.8/5/3600=340

3，秒杀商品

QPS：1000 个充电宝，10 个 iphone，假定当天 5 倍人参与，共 500 万，每个商品每人点击请求 3 次，秒杀请求发生在 1 分钟内。则 TPS=500 万*2*3/60=50 万

4.支付

TPS 热销商品：点击抢购后，进入支付界面，支付前查询商品剩余数量是否大于 1，支付后商品数量减 1，TPS 为 340。

TPS 秒杀商品：和上面逻辑一致，TPS 为 50 万。

四、存储架构设计

1.注册登录

假定有 5 倍的用户进行登录注册，存储的用户注册和登录信息 500 万

2.热销和秒杀商品库存

只有 200 条左右商品，但秒杀开始时，会有高并发库存查询，redis 单机 TPS 为 5~10 万，所以使用 redis cluster。

3.订单

预计登录用户有 50%的购买转化率，每人平均购买 2 件商品。则订单存储量为 500 万*0.5*2=500 万

五、负载均衡设计

初创公司，F5 价格过高，为满足峰值数百万的请求，使用多个 LVS 作为一级负载均衡。

六、缓存设计

App 缓存+web 容器缓存+分布式缓存

使用 APP 缓存和 WEB 缓存将大量静态页面保存起来，秒杀时静态页面从 APP 或 Web 获取，减轻后端压力。

秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对大流量，redis 采用 redis cluster 方式部署。

七、高可用设计

为确保在秒杀开启后，大流量冲击下万无一失，确保高可用，除了自建机房，需要购买一定的异地云服务，将数据同步到云中，发生本地宕机情况下，自动切换到云端。同时将请求放入消息队列，以应对高频请求，降低服务端压力。

八、可扩展设计

百万级别的业务，公司可以抽出 20 个左右开展这次秒杀业务，后端 12 个人，根据三个火枪手原则，开 4 个微服务，以后有新的业务可用直接水平扩展。