设计电商秒杀系统
【业务背景】
你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：
1.你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；
2.本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；
3.正常的日活大约 100 万用户；
4.老板要求万无一失。
【技术背景】
1.技术团队以 Java 为主，已经落地了微服务架构；
2.主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；
3.目前只有单机房。
【毕设要求】
1.设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；
2.大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。
【提示】
1.分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；
2.如果没有思路，请对照模块 9 的 IM 案例；
3.如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。
1.业务背景
你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：
1.你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；
2.本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；
3.正常的日活大约 100 万用户；
4.老板要求万无一失。
2.技术背景
1.技术团队以 Java 为主，已经落地了微服务架构；
2.主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；
3.目前只有单机房。
3.业务基本场景
1.使用手机号注册，每个手机号，只能注册一个账号；
2.账号要实名认证，未认证账号，不能参与秒杀；
3.商品购买流程，下单后减库存，后付款，有待支付订单有效期，半小时内支付，否则视为订单取消；
4.秒杀商品流程，和一般商品购买流程一致，入口在活动时间点，才开启；
5.秒杀商品，每人限购一件；
4.总体架构思路
正常的日活大约 100 万用户
大促活动期间，有 5 倍的用户量增长。预估用户注册为 500 万，日活按照 60%估算，所以按照百万用户级别，进行秒杀设计，适应最大业务需求。
基于现有微服务架构，可以快速落地，且方便拓展；
把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化；
在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载；将热点数据（如库存数据）单独放到一个缓存系统中，以提高“读性能”；增加秒杀答题，防止有秒杀器抢单。
对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面，而只需要点击秒杀按钮，借此把页面刷新的数据降到最少；
在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群。增加系统限流保护，防止最坏情况发生。
5.存储架构设计
百万用户存储性能估算
注册：
六百万用户注册信息.
登录：
正常日活用户 100 万，秒杀活动，按照 60%估算，登录数据是 360 万 qps。
浏览商品：
10 个品类，每个品类不超过 20 个商品；
两个秒杀商品；
商品的访问量= 10*20*360w=7.2 亿（每天访问量）
秒杀商品访问量= 2*360w*2（假设每个人刷 2 次）=1440 万
下单：
假设每天，每十个活跃有 2 用户下单 ，360w*20%=72w
秒杀库存为：1010 个
支付：
和下单量数量级类似
存储架构设计
600 万用户信息，1000 条商品信息，800 万订单信息，商品库存信息。支付单信息。
秒杀业务独立使用单独库。
库存库分拆，出现热点数据使用单独库。
6.计算架构设计
百万用户规模计算性能估算
注册：
估计短期新增注册用户每日 10 万，可以忽略。
登录：
因为活动使用的是 app，大部分都是提前登录好的。假设需要登录的 100 万用户，集中在秒杀开始前 1 小时，登录 TPS 均值：1000000/3600 约为 277。
浏览商品：
普通商品
10 个品类，每个品类不超过 20 个商品；
每次访问，需要更新商品库存信息，通过 redis 获取（redis 商品信息，每秒更新一次）
日活 100 万用户，每次看 50 个商品，80%集中在早中晚睡前 4 小时，则 QPS 计算为：1000000*50*0.8/(4*3600)=2778 QPS
两个秒杀商品；
使用 APP，提前缓存商品基础信息。假设 200 万参与秒杀，其中 50 万，是第一次查看秒杀商品，时间集中在秒杀前 1 小时，则 QPS 均值：500000/3600 = 139。
下单：
假设每天，每十个活跃用户下单 1 单，日单量为 10 万单
80%集中在早中晚睡前 4 小时，则 TPS 计算为：100000*50*0.8/(4*3600)=278 QPS
秒杀库存为：1010 个
秒杀共两个品类，1010 个商品，假设秒杀在 60s 内完成
假设有 200 万用户参与了秒杀，每个人发起了 2 次下单请求(APP 控制)，在 60s 内秒杀结束。
则请求 TPS 为：3600000*2/60 = 12 万 TPS
支付：
和下单量数量级类似
计算架构之负载均衡
考虑到 TPS 12 万，采用 LVS+nginx 作负载均衡设计、
计算架构之缓存架构
用 APP 对商品基础信息进行缓存
使用 cdn 做静态数据缓存，实现完全的动静分离
服务端做缓存防止压力全部到应用集群，防止热点读取
使用分布式缓存 redis，缓存库存数据
计算架构之高可用
考虑到下单请求很大，很集中，引入消息队列，进行削峰，具体来说
收到下单请求，直接丢入消息队列，并记录超时时间到 redis 集群
消息处理端，接收到消息，首先校验是否超时，超时则直接丢弃，未超时，则进行下单处理
客户端，轮询查询是否下单成功
限购与库存扣减
商品维度限制：比如我只想在北京、上海、广州、深圳这些一线城市投放，那么就只有收货地址是这些城市的用户才能参与抢购，而且各地区库存量是隔离的，互不影响。
个人维度限制：就是以个人维度来做限制，这里不单单指同一用户 ID，还会从同一手机号、同一收货地址、同一设备 IP 等维度来做限制。比如限制同一手机号每天只能下 1 单，每单只能购买 1 件，并且一个月内只能购买 2 件等。个人维度的限购，体现了秒杀的公平性。
采用下单扣减库存的方式，利用 Redis 的单线程原理，以及提供的原生 EVALSHA 和 SCRIPT LOAD 命令来实现库存扣减的原子性和顺序性，如果订单没有支付，采用定时任务取消库存扣减，释放库存。
限流
逐级限流，分层过滤，从访问链路，客户端浏览器访问商品详情，到最后下单做逐级限流
Nginx 限流，主要是依赖 Nginx 自带的限流功能，针对请求的来源 IP 或者自定义的一个关键参数来做限流，比如用户 ID
秒杀服务：通过线程池 限流
api 接口进行限流
我们可以用 Google 提供的 RateLimiter 开源包，自己手写一个基于令牌桶的限流注解和实现
大部分数据和流量在用户浏览器或者 CDN 上获取，这一层可以拦截大部分数据的读取；
7.其他架构设计
可扩展架构设计-微服务拆分
高可用架构设计 - 同城灾备
考虑到目前单机房可以承载，这个作为预案，如果老板了解成本后同意，才做。
大数据架构设计
使用 ClickHouse
1.兼容 SQL，维护使用简单；
2.性能强劲，OLAP 分析平台；
还未添加个人签名 2021-07-26 加入
还未添加个人简介
评论