你好，欢迎来到第 03 讲，这一讲主要介绍秒杀系统的非功能需求分析，特别是涉及高可用、高性能、高并发方面的内容。

前两讲，我们介绍了秒杀系统的前、后端功能需求，许多人在做业务系统时会发现，虽然功能自测、QA 测试、线上测试都通过了，但当线上环境出现变化（比如大量用户瞬间涌入），就会出现诸如系统瘫痪、数据错乱等问题，导致交易失败。

那如何预防此类问题，设计出稳定可靠的秒杀系统呢？这就需要我们这一讲介绍的非功能需求了。

什么是非功能需求？

我们先来回顾下需求分析的过程，当你接到一个项目后，除了分析功能需求外，还应该思考些什么？

也许，你会想到：

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

假如你能想到这些，说明你已经开始从系统功能以外来思考需求了。但仅仅解决这些问题，我们的系统就能正常运行吗？事情没那么简单。

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

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

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

举个典型的例子：

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

那么，为了在系统设计上防范此类重大故障，保证系统正常运行，我们该怎样分析非功能需求呢？

如何分析非功能需求？

首先，请你思考几个与非功能需求有关的问题：

• 假如总共有 100万用户，在同一时刻访问我们的系统，那么系统能否扛住？

• 假如 10 台服务器中有一台服务器因为物理故障瘫痪，剩下的服务器能否扛住？

• 假如服务器所在的某个机房发生了火灾，系统该如何继续运行？

• 假如有人在恶意攻击，系统该如何稳定运行？

• 假如请求超过 1 秒用户就会失去耐心，如何保障请求延迟低于 1 秒？

• 假如系统容量不足，如何做到 30 秒内快速扩容缩容？

这一系列的“灵魂拷问”，就是分析非功能需求的常用方法：假设在某些极端条件下，系统能否稳定运行，会面临哪些风险。这些极端条件我们怎么去找，怎么去假设呢？

我们可以根据影响系统正常运行的各种因素来假设。为了便于分析，我们将这些影响要素分为与系统运行环境有关的内部因素，以及与系统运行环境无关的外部因素。

那么，影响系统正常运行的内部因素主要有哪些呢？具体有这几个方面：

• 系统使用的语言和基础组件，比如采用 Golang 就意味着得到比用 PHP 更好的并发性能；

• 系统运行的服务器环境，比如采用多核 CPU 必然能提供比单核更好的性能；

• 服务器所在的机房环境，比如选择双电双网的机房将意味着比单电单网的机房更高的可用性；

• 机房所在的地理环境，比如选择无地震、洪水、台风的地区做容灾备份风险，将比在地震带低很多。

以上是内部因素，接下来咱们看外部因素，它主要有：

• 系统面向的用户群，比如一线城市年轻人、三四线城市用户；

• 用户群体数量有多大，比如 100 万用户量、2 亿用户量；

• 用户集中访问时间段，比如上班族是集中在下班后刷抖音，还是夜间 11 点刷；

• 用户可能会做哪些操作，比如疯狂点击按钮或者恶意攻击。

那么，这些因素在什么情况下可能给我们的系统带来风险？又该如何防控这些风险呢？

前面提到，非功能需求是系统在特定条件下正常运行的最低要求。所以，在系统的设计之初，我们就应当给这些最低要求赋予明确的定义，给出明确的指标。

对于秒杀系统来说，它的核心非功能需求主要有：高可用指标、高性能指标、高并发指标，比如可用性方面要高于 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%。

那么，在实际项目中SLA应该如何计算呢？SLA的计算规则如下。

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

假如四个子系统的SLA分别为 99.99%、99.995%、99.995%、99.999%，那么最终的 SLA 为 99.979%，整体SLA小于每一个子系统的SLA。

如果两个子系统作为主备关系提供服务时，只有两个子系统都出问题了才会影响整个系统，那么SLA=1-(1-SLA(a1))*(1-SLA(a2))。如下图所示，如果 a1 系统的 SLA 为 99.99%，a2 系统的 SLA 为 99.995%，那么系统最终的 SLA 为 99.9999995%。当然这是理想情况，主备切换也是需要耗费时间的，实际计算的时候需要将主备切换耗时考虑在内。

那么，影响SLA的因素都有哪些呢？以下列举一些可供参考：

• 服务自身因Bug挂掉或无法正常工作；

• 服务因机器物理故障导致无法正常工作，比如磁盘坏块、内存颗粒坏了、主板故障等；

• 服务器物理机因机房断网、断电、空调损坏无法降温等原因导致机房故障；

• 地震、洪水、台风等灾害导致机房损坏；

• 服务依赖的组件故障导致无法正常工作；

• 被黑客攻击导致无法正常工作；

• 并发量超过系统承载能力，导致系统崩溃、数据错乱。

以上各种原因都可能影响 SLA，只是概率不同而已。有的概率很低，对总的 SLA 影响较小。不过，有一个基本原则：下层系统的 SLA 在设计上通常需要高于上层系统的 SLA，只有下层系统的 SLA 足够高，上层系统的 SLA 才更容易得到保障。后面我们会有几节课专门介绍下层系统如何保障 SLA。

如何计算高并发指标？

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

不同业务的系统，对并发的要求可能不一样，比如 ToC 业务用户量大，对并发要求高，ToB业务系统可能用户量小，对并发要求相对较低。

即使同样是 ToC 业务系统，不同功能对并发的要求也可能不一样，比如抢购和秒杀对并发的要求会比下单的并发要求高。如何准确地评估高并发指标，这需要我们从用户增长、用户习惯、业务形态、系统承载能力等方面进行分析。

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

• 用户增长：月/年用户增长量是多少？是否有在社交平台推广？

• 用户习惯：秒杀活动期间是否跟用户活跃时间重叠？用户是否会频繁点击秒杀按钮或者刷新活动页面？

• 业务形态：是否是爆品？商品在购物车超时时间是多少？下单超时时间是多少？超时后库存是否需要归还？

• 系统承载能力：系统底层数据库等资源承载能力如何？业务系统是否要扩容？

总的来说，并发指标需要综合评估，还需要权衡成本和收益，毕竟大多时候并发能力需要靠堆机器来提升。

举个例子：

某电商通过观察数据统计得知，自己的日活大概有 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% 的余量，以便应对突发流量。

得到上面的数据后，我们还要通过压测来评估业务服务目前的容量是否达到要求，是否要扩容。

如何计算高性能指标？

在非功能需求中，除了可用性外，性能也是影响用户体验的因素之一。对于 ToC 的业务来说，如果请求超过 2 秒返回，会影响用户体验；如果在 5 秒内没有响应，用户可能就会离开。

那性能指标受哪些因素的影响呢？它的影响因素主要有：

• 用户网络环境

• 请求/返回数据大小

• 业务系统 CPU、内存、磁盘等性能

• 下游资源性能

• 算法实现是否高效

• 请求链路长短

怎么计算呢？举个例子，假设某秒杀系统的用户网络环境延迟 100ms，请求/返回数据处理为 10ms，业务服务内操作磁盘 30ms，业务服务请求下游资源 10ms，算法计算 5ms。我们把这些环节的延迟加起来，总共耗时将超过 155ms。

这个数值有什么意义？它说明，从用户发起请求到用户收到服务端返回的结果将超过 155ms。如果超过 150ms 会流失 10% 的用户，这可能是业务方不希望看到的，这个时候我们需要继续优化性能。

当然，不同并发压力下，请求延迟可能不同。通常来说，并发压力越大，平均请求延迟也越大。这好比排队买东西，排队的人越多，最后一个人买东西耗时越长。所以，我们在评估性能的时候，通常需要跟并发指标关联起来。例如，并发低于100万时，平均请求延迟不高于200ms。

通常，在实现完代码后，不一定确保性能满足要求，需要我们做大量的性能测试和性能调优来满足性能要求。后面我们会有专门的课时来介绍如何做性能测试和性能调优。

小结

这一讲我们分享了非功能需求的意义，它是除功能需求以外的、保障系统稳定运行的最低要求。对于秒杀系统来说，非功能需求主要有可用性指标、性能指标、并发指标。

如何分析非功能需求呢？分析的时候，我们需要充分结合业务特点和资源环境来综合评估。根据业务特点分析外部因素，根据资源环境来分析内部因素，综合评估出合理的指标，切忌盲目定指标。还有，并不是指标越高越好，满足过高的指标可能会浪费很多不必要的资源。

计算“三高”指标的时候需要非常清楚计算指标需要的各种参数，比如活跃用户量是多少、库存多少、网络质量怎样等。另外还要结合多个系统间的依赖关系，判定采用哪种计算方法，是并行关系还是串行关系。这样才能计算出较合理的指标，即满足业务要求，又不会投入太多额外资源。

思考题：一个日活 1 亿的公交支付 App，80% 用户活跃时间在 08:00 ~ 09:00 和 20:00 ~ 21:00，该如何给它定“三高”指标？

你可以把自己的想法写到下面留言区哦。

这一讲就介绍到这里了，下一节我们将介绍“如何设计秒杀的系统架构”。