秒杀预告话术（营销秒杀活动销售话术技巧）

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

3. 正常的日活大约 100 万用户；

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

业务基本场景

对前面的业务背景描述，进行核心业务场景假设，秒杀系统核心系统包括：

秒杀商品详情系统，秒杀交易系统商品库存系统支付系统存储架构设计存储性能估算用户信息

日活 100W 的系统，假设日活用户占 10%，注册用户有 100/10% = 1000W

商品信息

正常售卖商品数：10 个品类，每个品类不超过 20 个商品，总商品数目为：10*20=200 个商品，假设定期会对这些热销和好评的商品进行更新，更新评率为每周更新所有 200 个商品，为满足未来 2 年的增长，200*52*2=20000+商品

由于秒杀系统仅 618 使用，因此无需隔离热点商品信息，如后续需要演进为每日秒杀的系统，则可以做单独的热点商品存储和正常商品隔离

库存信息

假设每个上架的商品都是有库存的，库存记录数大致 20000+

秒杀库存，是否需要设计隔离的热点商品库存也看是否会演进每日秒杀的系统

订单信息

假设该电商系统 100W 日活用户，实际每日下单的用户占 50%，每日产生 50W 订单，满足未来 2 年增长 365*2*50=3.65 亿订单数据

支付信息

假设下单的用户都进行了支付，少量因为订单因为各种填写错误等原因未支付的订单，因此支付账单约 3.65 亿

存储架构设计

数据特点分析：

商品信息相对固定，包含商品介绍，图片等静态资源信息，读多写少，适合通过读写分离的方式，提高读性能的支撑，库存数据，频繁读写，对应秒杀场景，单库无法支撑写请求时，可通过库存拆分的方式分担写压力订单数据，支付数据未来可能持续增长，且数据量较大（上亿记录），存在明显的冷热特性，因此考虑对数据进行分片，按月拆分, 先做水平分表，后续再考虑分库

根据上面的分析，存储架构设计包括

分为商品、库存数据库、订单库、支付账单库，可先采用 MySQL 主从架构商品详情页动静资源分离，静态资源通过引入 CDN 存储进行加速用户信息、一些动态缓存的内容，以及秒杀过程中排队，可以考虑引入 Redis, 采用多机的 Cluster 架构计算架构设计

计算性能估算查看商品详情：假设 100W 用户全部参与秒杀，查看商品的 QPS 为 100W下单秒杀：比如增加答题等设计拦截下单请求，下单过程分散到 1~3 秒，下单 TPS 大致到 30W支付：支付过程由于一般较长，假设一般要 10 秒完成，支付 TPS 为 10W计算架构-负载均衡设计

采用多级负载均衡架构

第一级 DNS 采用专门的秒杀域名，和主站分离第二级采用 LVS 集群，第三级采用 nginx 集群计算架构-缓存设计

采用多级缓存架构设计

1.CDN 缓存静态商品信息，拦截大部分商品 QPS

2.APP 端缓存，秒杀预告预先放出了商品信息，可缓存部分资源到 APP 内部缓存

3.应用程序本地缓存，可存商品信息等

4.分布式缓存 RedisCluster 集群，存储用户信息，商品信息，秒杀限流任务队列