架构实战营模块九作业

设计电商秒杀系统

基本业务场景

设计思路

机房部署

• 秒杀系统实为当前电商系统的一个子系统；

• 为避免秒杀流量对当前电商系统产生不利影响，隔离原则，结合电商系统现状，只有单机房，准备把秒杀系统部署在同城的另一个机房；

• 秒杀系统中创建单独的数据库，主要包括活动商品表、活动库存表、活动订单表。

削峰限流

• 秒杀阶段的短时间流量会是平时正常流量的几十上百倍，甚至更多，不太可能也没有必要准备几十上百倍的设备及带宽，流量集中在秒杀商品页，及秒杀请求，可以用 CDN 来扛；

• 秒杀商品页为静态页提前把资源推送到 CDN；

• 假设一共 100 个 CDN 节点，每个 CDN 节点平均取前 1000 个请求，计 10 万个推给秒杀系统；

• 秒杀前 2 秒生成秒杀请求 URL，而且 URL 要经过加盐处理，防刷和作弊；

• 秒杀开始前，秒杀按钮不可用，提交秒杀请求后 5 秒内不能再次提交；

• 经过 CDN 限流，到秒杀系统后通过防刷、分层校验、限流削峰、限购、层层过滤，再经过库存查验扣减成功后的 1012 个流量进入到订单和支付流程。

库存查验 &扣减

• 采用 Redis Cluster 保存活动商品库存，两个商品库存分布在不同的切片上，提前预热，无过期时间；

• 考虑到原子性，使用 lua 脚本做库存查验+扣减处理；

• 库存扣减成功，即认为秒杀成功。

下单 &支付

• 下单失败，需要重试机制；

• 下单未支付超过一定时间，比如 5 分钟未付款，则订单取消，返回活动商品库存。

存储架构设计

用户量 & 关键行为

【用户量】

1.  正常日活 100 万，618 大促当日日活 300 万用户（参考其它电商平台 2021 年数据，大部分为正常日活的一点几到二倍之间）。

1. 假设 10% 的用户参与秒杀，即 30 万用户。也可以在 CDN 做边缘计算得出实际数量。

【关键行为】

1. 登录/注册；

2. 进入秒杀商品页；

3. 秒杀；

4. 付款。

用户行为建模和性能估算

【注册】

用户注册信息存在于当前电商系统。

【登录】

618 大促日活 300 万，即当天读取用户信息为 300 万 QPS，当前电商系统提供支撑。

【进入秒杀商品页】

进入秒杀页面，假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面，则页面请求为 1000QPS。提前生成静态页面，并推送到 CDN，由 CDN 提供支撑。

校对时间，进入页面后，需要每秒向服务器校时，则最高请求为 30 万 QPS。由 CDN 提供支撑。

【秒杀】

秒杀请求，30 万用户参加秒杀，30 万 TPS。

下单，一共 1012 个用户可以成功秒杀到商品，1012 条订单数据，这个量级可以忽略不计。

活动库存，两个商品，一共两条记录，忽略不计。

【付款】

一共 1012 个用户可以成功秒杀到商品，假设用户在 10 秒内完成付款，即 101TPS。

1012 条交易数据，这个量级可以忽略不计。

存储架构

数据量很少，主备数据库架构即可满足要求。

实际上没有必要再另外部署数据库，直接使用当前电商系统的数据库构架即可。

计算架构设计

计算性能估算

【注册】

当前电商系统提供支撑。

【登录】

618 大促日活 300 万，即当天读取用户信息为 300 万 QPS，当前电商系统提供支撑。

【进入秒杀商品页】

进入秒杀页面，假设参与秒杀的用户提前 5 分钟开始陆续进入秒杀页面，则页面请求为 1000QPS。提前生成静态页面，并推送到 CDN，由 CDN 提供支撑。

校对时间，进入页面后，需要每秒向服务器校时，则最高请求为 30 万 QPS。由 CDN 提供支撑。

【秒杀】

秒杀请求，30 万用户参加秒杀，30 万 TPS。

下单，一共 1012 个用户可以成功秒杀到商品，如果 1 秒完成，则 1012TPS，可以忽略不计。

【付款】

一共 1012 个用户可以成功秒杀到商品，假设用户在 10 秒内完成付款，即 101TPS。