计算性能估算

6.18 秒杀活动用户行为

秒杀商品查询、提交秒杀订单、秒杀成功订单支付

【秒杀商品查询】

1. 日活用户大约 100 万，6.18 秒杀假设日活 120 万

2. 秒杀活动假设在上午 10 点整开始，有 20%的用户会在 10 点参与秒杀，则 10 点秒杀最大 QPS 为：120 万*0.2 = 24 万/秒。

【提交秒杀订单】

1. 日活用户大约 100 万，6.18 秒杀假设日活 120 万

2. 秒杀活动假设在上午 10 点整开始，有 20%的用户会在 10 点参与秒杀，则 10 点秒杀最大 TPS 为：120 万*0.2 = 24 万/秒。

【秒杀成功订单支付】

存储设计

1. 数据库使用 MySQL，并且采用主备架构。原因如下：

• TPS 和 QPS 达到 24 万/秒，并发读写极大，因此必须使用缓存处理读写并发，处理结果先存储在缓存内，在秒杀结束后将结果写入到数据库即可，因此对数据库的读写性能要求并不大。

• 采用 Redis 缓存，缓存信息有：秒杀商品信息、秒杀商品库存数、已秒杀成功用户和商品的对应关系数据

2. 缓存存储使用 Redis 集群

3. 读写并发基本都是基于 Redis 缓存数据

4. 秒杀期间必须保证缓存可用，因此使用 Redis 集群

负载均衡设计

使用 nginx 作为负载均衡服务，一个 nginx 节点可以处理 10000 个并发请求，则需要 24 个节点，一个服务器部署 2 个节点，需要服务器 12 台。

缓存设计

只需分布式缓存，无需其他缓存，

应用缓存架构

分布式缓存框架使用 Redis，缓存数据如下：

1. 使用 List 数据结构存储秒杀商品信息，商品 ID 包含在 key 中，入：20211010_ProductId。

2. 使用 LIst 数据结构存储商品库存信息，一个库存在 List 中存储一条记录，因此 iphone 和充电宝分别在不同的 List 列表存储了 12 条记录和 1000 条记录。

3. 私用 Set 数据结构存储用户秒杀成功的商品对应关系数据，以防一个人秒杀了多个。

使用 Redis 缓存还有如下好处：

1. 可承载并发量大

2. Redis 单线程，可防止商品超卖情况

3. 丰富的数据结构

微服务设计

参考现有的成熟秒杀方案进行服务设计，经业务梳理分析得出业务模块图：

服务拆分

开发资源：全部 Java

服务开发资源分配：平均 2 个人开发一个微服务。

方案一：拆分成 3 个服务，商品服务、用户服务、秒杀服务

备选方案二：拆分成 2 个服务，商品服务、用户服务

微服务划分

• 商品服务包含商品业务、品类业务、库存业务，三种业务关联比较大，先作为一个服务处理，后续随着业务需要可按需拆分，当前为一个粗粒度划分。

• 用户服务包含用户业务、登录业务、订单业务等，三种业务关联大，后续可将订单独立。

• 秒杀服务包含秒杀业务逻辑

基础设施选型

服务注册、发现、路由选择嵌入式 SDK，原因如下：

• 统一 Java 语言，无需考虑多语言版本，学习成本小，出现问题可快速定位

• 使用简单，无需维护高可用、高性能，运维简单

• 网络代理和反向代理运维麻烦，成本高，不在现有的运维体系，出现问题排查困难

• 适合从 0 开始的项目进行快速开发上线

• 由于初创公司，嵌入式 SDK 可以节省成本，随着业务增长后续可切换成反向代理或网络代理

开发框架选择 SpringCloud，原因如下：

• 整套的微服务技术体系，资料文档比较全，专用开发组件丰富，运用广泛，运用后排查问题方便

• 微服务之间通信简单 http 即可，SpringCloud 已提供

• SpringCloud 的注册中心 eureka 满足嵌入式 SDK 需要

• SpringCloud 提供完善的链路追踪、熔断降级、网关等组件，拿来即用

高可用设计

因为只有一个机房，所以无需考虑跨机房同步。

• MySQL 采用主备

• Redis 使用集群

架构设计

秒杀系统架构图

系统架构一：

系统备选架构二：