业务

登录

       改密码

       找回用户

注册

浏览（包含匿名）

购物车

结算，下单（checkout）

账户

       User info

       Order history

       Payment

       Address

App 下载高峰

架构

总体分析

日活 100 万，每天活跃 40%，预估 250 万人已注册。由于平台活动力度大，宣传做得好，活动期间新增了 30 万用户。

预估秒杀当天登陆的 QPS 有 230 万（200 万来自活动以前注册用户，30 万是活动期间注册的），抢单的 QPS 有 180 万。

暂时忽略匿名浏览，匿名下单。

当天场景

230 万人登陆（读取用户数据）

假设从活动推广开始（提前 10 天），有 10 万新用户注册（写入，预计有 10 万，10 万也是 app 的下载数量）

假设有 20%的人检查支付方式，230 万*20% = 46 万；有 10%的人修改支付方式，230 万*10% = 23 万。

假设有 30%的人检查收货地址，230 万*30% = 69 万

假设有 30%的老用户需要修改密码或找回用户，200 万*30% = 60 万。

10 个品类，每个品类不超过 20 个商品。最多有 200 件商品。被挑选售卖的商品都是畅销商品和好评很多的，预计每人会浏览 60%的商品。230 万*200*60% = 2.76 亿次浏览

假设有 10%的浏览被加购物车，2.76 亿*30% = 8280 万次

被挑选售卖的商品都是畅销商品和好评很多的，假设 60%的购物车被最终下单，8280 万*60% = 4968 万次。

商品被卖出后减库存，最后一件商品被卖出后改状态，但不下架。

下单关联商品和用户（用户基本信息，收货地址，支付方式）。

存储

每个业务分别有多少条数据？

登陆信息读取：230 万/天

新用户注册（写入新用户）：10 万/天

app 的下载数量（app 读取）：10 万/天

检查支付方式（读取）：46 万/天

修改支付方式（更新）：23 万/天

检查收货地址（读取）：69 万/天

修改密码（更新）：60 万/天

找回用户（读取）：60 万/天

浏览商品（读取）：2.76 亿/天。每次加载商品页面，会加载商品，库存，和价格，所以加载商品的真实读取是 8.28 亿/天。由于对商品，库存，和价格的请求是不区分用户的，这些数据可以缓存在 Redis。

加购物车（写入）： 8280 万/天

虽然有 4968 万/天下单请求，但是成功下单的只有 200（商品数量）。所以下单（写入）：200/天

存储架构

价格（原价和折后价），商品，登录状态存 Redis。其他可以走 DB。

采用主从集群，提高机器利用率。

计算架构

注册

假设从活动推广开始（提前 10 天），有 10 万新用户注册。最多一天有 3 万人注册，时间分布在 12 个小时内。30000 / (12 * 60 * 60) ≈0.7 个请求/秒。活动开始前一小时有 1 万人注册，10000/ (60 * 60) ≈2.8 个请求/秒。可以忽略不计。

登录

日活 100 万，每天活跃 40%，预估 250 万人已注册。由于平台活动力度大，宣传做得好，活动期间新增了 30 万用户。

预估活动推广前 250 万人已注册。日活 100 万已经处于登录状态。假设登录状态可以保持 10 天，假设额外还有 80 万人处于登录状态，活动期间新增了 30 万用户都是处于登录状态。活动当天有 250-180=70 万人需要登录。预估有 30 万人在活动开始前 2 小时内登录，30 万 / (2 * 60) = 2,500 次登录/秒。

浏览

浏览商品 2.76 亿/天都走 Redis。QPS 是 2.76 亿 * 3 / (24 * 60 * 60) ≈ 3190 次/秒。

假设 30%的流量都在最后两小时，2.76 亿*30% / (2 * 60 * 60) ≈  11,500 次/秒。

下单

加购物车 8280 万/天。假设 30%的加购物车都在最后两小时，8280 万*30% / (2 * 60 * 60) ≈ 3450 次/秒。

下单请求有 4968 万/天，假设 20%的下单都在最后一小时，4968 万*20% / (60 * 60) ≈2760 次/秒。

负载均衡

QPS+TPS = 2,500 次登录/秒 + 11,500 次/秒 + 2760 次/秒 = 16,760 次/秒。

假设单机性能 500 QPS，需要 34 台机器。预留 10%的性能，需要 38 台机器。

缓存

采用 APP 缓存 + web 容器缓存 + 分布式缓存

因为只有用 app 才能参与秒杀，所以用 app 缓存已经浏览过的商品和静态资源。

web 容器缓存缓存应用部署相关资源。

分布式缓存如 Redis，缓存商品和价格。

高可用

用户数量还不到值得做异地多活的，可以做同城跨区双中心

下单后，可以由任务分解器去分别更新库存，订单状态。在存储方面，只有 200 个订单，集群间可以采用复制数据的方式，暂时用半同步方式。

可扩展

已经落地微服务。预估团队有 50 人，根据“三个火枪手”原则，可以拆成 16 个微服务。