毕业设计

题目：

设计电商秒杀系统【业务背景】你作为一个电商创业公司的架构师，负责设计 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. 需求分析

1）挑选好评的商品进行销售，那么需要一个可配置的运营平台，以支持灵活调整具体的品类

2）10 是个相对来说很小的数字，且 iphone12 是热门商品，因此可以做简单的时间+点击限流策略；1000 个充电宝相对来说数量不少，秒杀的策略和 iphone 有差异，可能需要做更精确的点击限流策略

3）日活 100w，是个不小的数字，因此秒杀活动绝不能影响原有的业务系统

4）万无一失包含多重含义，既不能让原有业务系统宕机，也要保证秒杀活动的正常进行，同时还要达到引流目的，在业务上避免被人薅羊毛（都被少数客户刷走了）

1. 概要设计

1）设计首先要保证安全性，所以在已有微服务框架基础上，新建单独的秒杀微服务；同时百万日活级别的系统，不太可能没有单独的后台管理系统，因此不考虑再新建秒杀商品配置的运维功能；同时假设后台管理系统数据库已经与业务系统数据库做了隔离，因此也不需要再单独新建秒杀微服务的数据库。

直接使用管理系统数据库进行商品配置、存量预设的处理

2）秒杀系统需要支持不同数量级库存商品，设置不同秒杀策略的功能，因此需要有系统+业务层面的限流控制。系统层面可以通过 ng+lua 脚本的方案控制，业务层面需要灵活配置，可考虑使用缓存进行初始化或使用 nacos/apollo 等配置中心

3）目前只有单机房，因此出现意外必须要支持数据恢复。从缓存层面看，需要进行持久化；数据库需要进行主备操作，mysql 用的比较少，pg 的话有 dts 这种准时同步工具，几乎可以认为是秒级备份，因此按照 mysql 也有同样性能工具设计主备储存；

1. 详细设计

1）系统架构图

如下图所示，在原有的系统外，新增秒杀子系统，通过路由，将秒杀服务转到秒杀子系统上，因此初步的架构如下图

2）细化组件及方案选型

细化后的架构图如下，逐一说明

首先业务系统量级，可以基本确定是较大的公司，因此会有自己的 F5 服务，故使用 F5 作为一级负载均衡，在 F5 后，使用 ng 作为二级负载均衡。这个架构是当前非常成熟的方案，因此基本可以确定原有的业务系统也会按照这个来设计。我们本次增加的秒杀子系统，可以通过 ng 进行引流，专门处理秒杀活动的 url，同时也可以鉴别请求来源，仅允许 app 端的请求参与秒杀。

在秒杀子系统前我又加了一个 ng，目的是为了可以配合 lua 脚本，进行时间控制。上文提到的 iphone 秒杀，只有 10 台，因此基本开始 1 秒就可以结束了，所以就可以通过 lua 脚本，将超时秒杀 iphone 的请求直接转向固定页面，告知已被抢完，降低服务器负载。

在最右方，新增了 redis 用于存储秒杀货物存量。redis 使用 cluster 集群部署，通过运维平台设置各种秒杀商品数量。因为题目中没有涉及到特别大的数据量，故只使用 cluster 作为主从，不做数据分片。当秒杀成功，由秒杀子系统发起请求，通过 redisTemplate 进行扣减，扣减成功生成订单，通过消息队列 kafka 给到业务系统，由业务系统调用原有的下单-支付业务流程。注意这里不会在秒杀系统里重写下单支付等方法，而是复用原有的业务系统功能。

3）“万无一失”的处理方法

主要考虑 2 种可能出现的问题。一是硬件方面，比较可能的是机房断网、机房断电；二是软件方面，比较可能的是服务出现问题，例如访问过大导致瘫痪，以及各种原因导致数据丢失。

因为题目中说明了公司是单机房，因此需要向老板说明方案，并明确单机房可能导致的问题，并说明解决方法，例如再建一个机房、上云等，最终由老板定夺；软件方面需要做好压力测试，按照现有 tps 预估活动当天会有多大的请求量，通过动态扩容、服务降级等方式进行支持。

现在假设老板觉得秒杀活动比较近了，来不及做其他方案，那么我们只做备份方案，先告知他可能的问题，并建议如果出问题，可以在当天更迟时间再进行一次秒杀活动，老板基本也都会接受。

那么所有的关注点都集中到保证服务稳定，保证数据不出问题上了。前面说到压测，可以比较准确的评估服务器压力，按照压测结果增加服务器数量，并做一定量的冗余（例如 10%），保证系统压力不会过大；同时进行数据库主备，采用同步工具例如 binlog 保证数据不丢失，开启 redis 持久化配置，保证断电重启后数据可恢复