打造千万级流量系统——秒杀系统（需求篇）

一、功能需求分析

1、前端需求分析

前端是一个系统中离用户最近的部分，为用户提供信息展示、交互逻辑等。当前端的需求基本决定，一个系统的功能需求也就随之产生。所以，接下来，我们重点分析一下秒杀系统前端的需求。

1. 秒杀详情页

首先，作为电商的子功能模块，秒杀通常不会直接出现在首页上，而是有一个单独的秒杀详情页，首页作为它的流量入口。用户会先打开平台首页，从首页秒杀入口进入到秒杀功能模块的页面。

当用户通过首页入口进入到秒杀页面后，他希望看到什么信息呢？应该是有关这场秒杀活动的详细信息，比如活动场次、秒杀商品、秒杀价格，活动规则等。对我们来说，这就是秒杀详情页。

详情页会展示多场秒杀活动信息以及每场秒杀活动的商品信息，让用户选择自己感兴趣的活动场次。比如今天 9:00 ~ 10:00 是小米手机专场，10:00 ~ 11:00 是红米手机专场，11:00 ~ 12:00 是生态链产品专场。

因此，秒杀详情页需要划分两个展示区：活动场次信息区、活动商品列表区。活动场次信息区里可以点击场次按钮切换场次；活动商品列表区里可以点击某个商品的按钮查看商品详情。

2. 查看商品列表

接下来，用户可能会点击活动场次信息区的某个场次，查看该场次的商品列表。像点击“出行穿戴”专场，就可以查看所有参与秒杀活动的穿戴商品，比如小米手环 4 NFC 版，大屏彩显，可刷公交和门禁，原价 229，活动价 179，库存剩余 8%等信息。

对应到前端需求当中，就是商品列表区的商品信息——商品图片、商品名称、广告语、库存信息、原价、活动价、秒杀按钮。

接下来，用户可能直接点击商品按钮，这里会出现 3 种情况：

活动已开始，对于已登录用户来说，按钮提示“立即抢购”，点击后会跳转到商品详情页；

活动已开始，对于未登录用户来说，按钮提示“登录后抢购”，点击后会跳转到登录页；

活动未开始，按钮则会提示“提醒我”，点击后就会订阅活动通知。

最后，当用户进入到商品详情页，可能希望看到诸如“原价 229，活动价 179，距离结束还剩 15 分钟”的活动信息；“全新 AMOLED 大屏彩显，手环刷公交卡、门禁卡，能用支付宝抬手支付……”的商品描述信息；“黑色”“白色”等规格选项；“北京朝阳区”“上海浦东区”等配送区；是否有货的库存信息。这些就是商品详情页的前端需求。

以上就是用户参加秒杀活动时，在前端页面出现的行为及需求，具体落实到前端设计，主要包括 UI 设计和交互逻辑。

3.UI 设计

UI 设计主要包含秒杀系统各个功能页面的内容和布局，大致有 3 类：首页入口、秒杀活动页、商品详情页。

4.交互逻辑

介绍完 UI 设计，我们来说下交互逻辑。所谓交互逻辑，主要包括页面上各个部分对用户行为的交互方式和响应结果，它是基于 UI 设计页面来进行的。我们还是以首页入口、秒杀活动页、商品详情页来介绍。

首先来看首页入口，它的交互逻辑是“点击秒杀广告位进入秒杀活动页”。

秒杀活动页，它存在四大交互逻辑，请看下面的流程图。

当用户进入活动页，如果当前页面显示的就是他想要的场次信息，那么他就会参与其中。
活动场次切换，如果当前显示页面不是他想要的，用户则会点击切换场次，这就是用户点击切换，还有一种是自动切换，它需要设定定时任务判断时间，到了时间则自动切换，切换后系统自动重新获取活动场次信息。
接下来，为了找到自己想买的商品，用户会点击活动详情区的商品，进入到商品详情页。
活动详情区商品的按钮。如果是活动已开始，未登录用户会提示“登录后购买”，点击则会跳转登录页；如果是已登录用户，则会提示“立即抢购”，点击后会跳转到商品详情页。如果活动未开始，则会提示“提醒我”，点击订阅活动通知。

最后，我们来介绍下商品详情页上的交互逻辑。它有三类交互，请看用户操作流程图。

第一个交互，点击配送区修改按钮，选择配送地区；

第二个交互，点击规格按钮，选择商品对应规格；

第三个交互，点击秒杀/购买按钮。这里会出现两类状态，一类是活动进行中，一类是活动未进行。

在活动进行中，如果是未登录用户，则会提示“登录后购买”，然后点击跳转登录页；如果是已登录用户，则会提示“立即抢购”，点击后若抢购成功，将商品加入购物车，商品享受活动价。若抢购失败，根据后端返回，给出失败提示“活动已结束”或“已售罄”。

活动未进行，交互逻辑会提示“加入购物车”，点击后将商品加入购物车，商品不享受活动价。

另外，由于用户量大，页面需要采用前后端分离、动静数据分离的方式，静态资源和静态数据由 CDN（Content Delivery Network，内容分发网络）和前端缓存，尽量减少对后端的压力。

对于一个秒杀系统来说，需求分析是一个项目中最关键的环节之一。只有把需求弄清楚了，在项目落地的时候方向才会有的放矢，才能设计出既满足业务需求又能稳定运行的业务

2、后端需求分析

这部分主要包括需求分析及其接口，还有隐藏需求。

1.需求分析

后端的需求依赖于前端。为了分析后端需求，我们需要先了解用户在秒杀活动中的行为。

首先，他会先打开官网首页，点击首页的秒杀入口，进入秒杀活动页。

第二，当他进入秒杀活动页后，必然要了解活动信息，比如双十一有哪些场次，都有什么优惠，以及自己要买的东西在哪场。为此，我们需要为用户提供一个获取活动信息的接口。

第三，假设手环和耳机都在上午场，为了找到它们，这名米粉会点击场次按钮来了解。那么，这些场次信息就需要我们在后端提供，且最好是能缓存在页面，避免因每次请求而给后端带来压力。

第四，为了避免错过活动，他会点击上午场里手环和耳机的提醒按钮订阅通知。此时，后端需要判断他是否已登录 App。如果是，则生成一条 Push 订阅记录，并返回已订阅人数；如果没有登录，则提示他先登录。

第五，假设现在已经到了上午场活动开始时间，这名米粉开始进入手环的详情页，去了解它的价格、库存、活动信息等，判断要不要购买。

这个环节需要我们在后端提供手环的商品信息，特别是它的配送区信息、库存信息、活动信息。其中，库存信息和配送区并不是秒杀系统本身的主要内容，可以简明扼要，而活动信息则是秒杀系统的数据之一，需要提供接口获取该商品是否参与秒杀活动。

最后，假设这个米粉看了促销信息，觉得划算，他就会点击秒杀按钮进行购买。此时，后端需要判断他的登录状态：如果未登录，则跳转登录页；如果已登录，则判断是否参加秒杀活动、是否有库存、是否有资格，满足条件则扣预留库存、加购物车，并返回结果。

这是我们假设一名用户访问前端秒杀活动的行为轨迹，通过它，我们分析出了后端需要哪些需求。

2.接口清单

根据上面的需求分析，我们不难发现，点击场次信息时是从前端缓存里提取数据，所以不需要后端接口，而其他 4 种行为则需要对应的后端接口以便和前端互动。具体如下：

对应秒杀活动页需求的秒杀活动信息列表接口；
对应提醒按钮需求的 Push 订阅接口；
对应商品详情页需求的商品活动信息接口；
对应秒杀按钮需求的秒杀抢购接口。

3.隐藏需求

为了获取库存信息，需要对接库存中心；
为了获取商品信息，需要对接商品中心；
为了操作购物车并生成订单，需要对接交易中心；
为了方便做数据统计，需要将秒杀成功的用户 ID 记录下来，以便对接账号中心验证用户账号合法性。

另外，还需要支持灰度测试，以便我们在正式上线前，及早发现测试环境中无法暴露的问题。

最后，为了抗住大流量，还需要做一些维护服务稳定性相关的工作。

总之，后端的需求不像前端那么直观，有原型图参考。特别是隐藏需求，它比较依赖后端研发人员的经验来分析。

3、管理后台需求分析

1.需求分析

那么，每个商品的信息从哪里来呢？主要有两大来源：

从其他系统中获取，比如名称、描述、图片等商品基本信息，价格、库存等销售信息；
从管理后台中录入，比如商品 ID、活动价格、活动库存、限购策略等。

一般大型促销专题活动通常是由多场活动组成。比如：双十一大型促销专题活动里可能包含上午场和下午场两场活动，每场活动里有 10 件参与活动的商品。所以，在活动信息编辑功能里，我们还需要三个数据录入功能：活动专题信息录入、活动场次信息录入、商品信息录入。

2.后台页面

从大到小，大致有这三类：

活动专题管理，主要是用于管理所有秒杀活动专题，包括专题列表页和专题编辑页；
活动场次管理功能，用于录入秒杀活动场次信息，并关联到专题上，包括场次列表页和场次编辑页；
商品管理功能，用于管理参与秒杀活动的商品信息，包括商品列表页和商品编辑页。

首先，我们来介绍下第一类——专题管理，它包括专题列表和添加专题这两个页面。

第二类后台页面——场次管理

场次管理也包括两个页面，一个是“场次列表”，一个是“添加场次”。

其中，场次列表就是针对一个秒杀活动的场次信息。比如 2020 年双十一秒杀活动，它有两个场次——生态链第一场和生态链第二场。每个场次都有各自的场次 ID、关联专题活动、描述、开始结束时间、状态和操作选项（查看、编辑、上线、下线）。

添加场次，就是把每一场的活动信息都添加上，请看下图。

这一页的信息主要有场次关联的活动专题、开始结束时间、场次描述、限购策略、商品、添加按钮，以及最后的信息提交/取消按钮。

这是活动场次管理，场次之下就是具体的商品管理了，前面提到过，它包括商品列表页和添加商品页。我们来看这个原型图。

注意：

提交按钮点击后需要给出提示，成功后跳转到相应列表页，失败则给出具体的失败提示，以便运营同学和研发同学快速定位问题。

各功能列表项中查看操作的页面内容，类似于编辑页面，只是查看页面中内容不可修改。

对于进行中或已结束的场次，查看页面需要展示每个商品的剩余库存，以及秒杀成功的用户名单。

3.接口清单

当然，对于管理后台来说，前后端分离在技术上是大势所趋。所以，除了页面需求外，为了前后端交互方便，管理后台也有接口需求。从以上后台需求分析中，我们可以整理出后台接口大概如下：

管理后台基本上是增删改查的操作，接口设计最好是符合 RESTFul 风格。查询接口需要支持批量查询和单个查询。

在需求分析的时候，为了考虑全面，我们可以站住不同的角色立场来分析，比如站在用户、产品经理，前后端研发、测试人员、运营人员等的角度来看待。

有时候我们拿到的需求并不是详细的需求文档，可能仅仅是个原型图，这时就需要我们充分与业务方沟通，并将沟通结果整理成可拆解的需求点用文档记录下来，以便后续做详细设计和任务拆解。

另外，我们还需要挖掘出隐藏需求，以免评估工作量的时候有疏漏，导致项目延期。

二、非功能需求

除了分析功能需求外，还应该思考些什么？

这个系统的用户是谁？
有多少用户？
用户都在什么时间使用系统？
用户可能会做哪些危害系统的操作？

除了外部，我们还需要更多地从内部因素考量，比如运行系统的机器配置、语言并发能力、机房可用性等等这些是否满足要求。像这种除用户使用功能之外的潜在需求，就是非功能需求。

非功能需求包括：可用性、并发能力、性能、安全防护能力、水平扩容缩容能力、运维/运营成本等。

比如，我们在设计一个重要系统时，可能会要求可用性达到 99.99%，并发能力达到 100 万 QPS，请求延迟低于 500ms，能防范跨站脚本攻击，1 分钟内快速扩容，总成本控制在 10 万元每月。这些要求就是非功能需求要满足的。

为什么要关注这些指标？因为如果没有满足这些指标，系统在运行的时候，会出现重大故障。甚至可以说，满足它们是系统在特定条件下正常运行的最低要求。

举个典型的例子：

某个金融系统要求每年最多只能发生一次故障，故障时间不能超过 10 分钟，为此他们还准备了故障赔偿金。但是在项目部署的时候，相关人员因为没有充分评估机房的网络质量，结果在两次流量高峰时都出现了故障，不仅影响用户体验，还导致赔偿金严重超支。

1.如何分析非功能需求？

对于秒杀系统来说，它的核心非功能需求主要有：高可用指标、高性能指标、高并发指标，比如可用性方面要高于 99.99%，高性能方面要求请求延迟小于 100ms，高并发方面要求QPS 大于 10万。这三个指标俗称“三高”要求，公司不同，指标大小要求也会有所不同。

如何计算高可用指标？

高可用指标是指用来衡量一个系统可用性有多高。这里有几个需要了解的概念：

MTBF（Mean Time Between Failure，平均可用时长），系统正常、稳定运行的平均时长，比如三天内系统出现了3次故障，每次持续1小时，那么平均可用时长是23小时；
MTTR（Mean Time To Repair，平均修复时长），系统从失效后到恢复正常所耗费的平均时间，比如前面提到的每次故障持续1小时；
SLA（Service-Level Agreement，服务等级协议），用于评估服务可用性等级，计算公式是MTBF/(MTBF+MTTR)，一般我们所说的可用性高于 99.99%，是指 SLA 高于 99.99%。

通常我们在看监控数据的时候会关心这个指标。在使用第三方服务和平台的时候也会关注第三方平台的可用性指标，如某第三方支付平台可用性高于 99.999%。

如果一个系统的正常运行还依赖多个子系统，如下图所示，系统中有 a、b、c、d 四个子系统，只要其中一个子系统不正常，整个系统就无法正常工作，那么整个系统的 SLA = SLA(a)*SLA(b)*SLA(c)*SLA(d)。

如果两个子系统作为主备关系提供服务时，只有两个子系统都出问题了才会影响整个系统，那么SLA=1-(1-SLA(a1))*(1-SLA(a2))。

2.如何计算高并发指标？

通常我们用 QPS（Queries Per Second，每秒查询率）来衡量系统承载能力。

对于秒杀系统来说，通常用户数都是远大于库存数的。库存一旦抢完，秒杀活动基本结束。我们可以针对秒杀活动的特点，做以下分析。

用户增长：月/年用户增长量是多少？是否有在社交平台推广？
用户习惯：秒杀活动期间是否跟用户活跃时间重叠？用户是否会频繁点击秒杀按钮或者刷新活动页面？
业务形态：是否是爆品？商品在购物车超时时间是多少？下单超时时间是多少？超时后库存是否需要归还？
系统承载能力：系统底层数据库等资源承载能力如何？业务系统是否要扩容？

举个例子：

某电商通过观察数据统计得知，自己的日活大概有 600 万。活动期间，运营团队在社交媒体上推广，预计可拉新 50 万，那么活动当天日活大概就有 650 万。根据经验，活动期间活跃用户占日活用户 70%，那么参加这场活动的活跃用户大概有 455 万。

假如有一爆款商品，库存只有 1000 件，预计会有 30% 的活跃用户参加秒杀，那么参与抢购的人大概是 136.5万人。假如每个用户每秒触发 2 次请求，那么业务服务承载的 QPS 最高可能达到 273 万。另外，我们还知道它的底层 Redis 承载能力为 1 万 QPS。

根据业务服务承载最高值达 270 万 QPS 以及底层 Redis 承载能力 1 万 QPS，我们预留 10% ～ 20% 的余量，可以初步制定出并发指标：业务服务300万QPS，底层资源 8000QPS。

这里你可能会问了：为何业务服务的 QPS 要比实际的高，而底层资源 QPS 却比实际承载能力低呢？

其实这是一种保护措施：业务系统设计上保留余量，要比计算出来的 QPS 高一些，以防实际突发流量高于估算值导致系统不稳定；底层资源一般比较固定，不容易扩容，需要限制QPS不能超过其承载能力。总的来说，系统资源在设计上要留有 10% ～ 20% 的余量，以便应对突发流量。

引自：拉勾打造千万级流量系统