高并发 -1- 压力预估

讲个故事：

下个月就是双十一了，运维团队开始咨询各个业务团队 TL 服务器扩容规模。李雷收到消息，直接就给了个十倍扩容，声称我们营销团队给公司每年带来几个亿的营收，大促期间扩容十倍机器只是小钱。张三收到消息，不知道要扩几倍，就看了看别的团队，财务团队扩了两倍，那我们商品团队就加一点扩容三倍吧。结果李雷团队的部分服务顶着 10 TPS 部署了百来个节点，存在大量无效投入；张三团队由于大促峰值流量直接打崩了服务，出现了 1 个多小时的服务不可用，急急忙忙扩容以支撑后续访问。事后，张三因为救火有功得了个优秀员工奖，但 1 小时的服务不可用造成了千万级损失，整个研发团队绩效清零，

要解决上诉问题，首先要对企业经营保持敬畏之心。哪怕只是一个大促扩容预估，做错了，也可能牵扯出财产千万，是非曲直等一系列问题。接着，要有一套压力预估和容量测算的科学方法，以便于支撑合理的扩容决策。

关键指标介绍

要做压力预估，首先要对一些性能指标有基本认知：

业务指标：

• 目标用户数：目标用户数是所有可能访问我们系统的潜在用户的总和。它反映了潜在的市场规模。举例来说，微信的目标用户数可以是中国的人口总数，约为 13 亿人。

• 系统用户数：系统用户数是所有访问过我们系统的用户的总数。成功的系统通常会吸引更多的用户使用，因此系统用户数和目标用户数越接近越好。举例来说，如果某社交媒体平台有 10 亿的目标用户数，而实际上已有 8 亿用户使用过该平台，那么系统用户数就是 8 亿。

• 活跃用户数：活跃用户数是在一定时间范围内访问过我们系统的用户的数量。这个时间范围可以是一个月，一个星期或者一天。举例来说，如果一个在线游戏在过去一个月内有 5000 万名用户登录过至少一次，那么月活用户数就是 5000 万。

• 日活用户数：日活用户数是在一天内访问过我们系统的用户的总数。这个指标可以帮助我们了解系统在一天内的活跃程度。举例来说，某社交网络平台在某一天内有 1000 万用户登录过至少一次，那么该平台的日活用户数就是 1000 万。

• 在线用户数：在线用户数是正在使用我们系统的用户总数。这个指标可以帮助我们了解系统当前的负载情况。举例来说，某在线购物网站当前有 50 万用户正在浏览商品，那么在线用户数就是 50 万。

技术指标：

• 吞吐量指的是，系统在一定时间内可以处理的任务数。比如评判一个食堂阿姨的打饭速度，你可以统计下午餐时间，一个小时内她能打多少个学生的饭。常见的吞吐量指标有 QPS、TPS 和 BPS。

• QPS，即查询数每秒，用于衡量一个系统每秒处理的查询数。

• BPS，即比特数每秒，用于衡量一个系统每秒处理的数据量。对于一些处理大量数据传输的系统，仅 QPS 和 TPS 不好表达其吞吐量高低。因为这类型系统相对于响应频次更关注传输的数据量，10QPS 传输 10M 数据是不如 1QPS 传输 100M 数据来得好的。

• TPS，即事务数每秒，用于衡量一个系统每秒处理的事务数。这很好理解，但它很难对齐。因为 TPS 的 T 在不同的行业、不同的业务中定义的口径都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人对 T 得口径要先达成共识。一般我们有这些级别：DB 级别，即一次 DB 事物为一次 T，比如写入订单到 DB；业务级接口级别，即一次业务级写接口操作为一次 T，比如创建订单（里面包含了查询商品、扣减库存等一系列操作）；用户操作事物级，比如一次购物操作，里面包含查询商品列表、点击详情、创建订单、支付订单、下发仓库、仓出库。

• 并发用户数：并发用户数是指同时发起请求并且服务器正在处理这些请求的用户数量。这个指标对于架构设计和性能优化非常重要。举例来说，某视频直播平台的并发用户数是指同时观看直播并且服务器正在为他们提供视频流的用户数量。

• 并发连接数，表示同时与服务建立的连接数量。每个连接可能对应着一个任务或一个并行执行的操作。TPS 并不能表达服务能提供的并发峰值上线。比如一个接口，平均 RT 为 200ms，能支撑的 TPS 为 100（业务接口级的 T），那么其最大并发连接数等于 20（ 20 = 100 * 200 / 1000），如果请求不是均匀的到达接口，而是一次性打过来的 100 个请求，那么只有 20 个可以正常被处理，80 个只能等待或者直接失败。

预估案例

在上述案例中，大促场景实际上是高并发场景的一个典型案例。高并发的主要挑战在于瞬时激增的大量用户请求需要同时使用大量的计算资源。为了解决这一挑战，互联网应用采取了水平伸缩的发展道路，即分布式架构。通过不断横向扩展集群节点来增加计算资源，所以掌握分布式架构等同于掌握高并发系统设计的核心。后来虽然 devops 发展出了自动伸缩扩容的技术，但在真正的高并发场景下表现不尽人意，可能造成用户体验下降，甚至导致长时间服务崩溃停摆。因此，应对真正的高并发主要还是依靠合理的压力预估、容量测算以及一系列消流和消峰的应对措施。合理的压力预估的基本思路是筛选出关键的技术指标，然后通过业务指标按实际情况乘以一定的系数，做单位换算，最终转换成技术指标。

电商案例

假设我们要设计一个国内的自营电商平台，就叫中华优选目标用户数是中国的人口总数，约为 13 亿人。

电商平台的模块非常繁杂，包括分销侧和供给侧。分销侧模块涵盖账户、积分、商品、营销、购物车、交易订单、支付、销售库存等功能，而供给侧模块包括履约订单、物流、仓储、财务、全渠道库存、采购、供应商等功能。本次压力预估重点关注分销侧的交易订单和供给侧的履约订单，在日常和大促两个场景下的预测情况。在交易订单方面，核心关注创建交易订单的并发连接数；在履约订单方面，核心关注事务处理能力（TPS）。

业务指标盘点（与业务同学做工作坊的模式）

• 目标用户数<业务>：13 亿

• 系统用户数<业务>： 1.3 亿（前三年假设初期用户做到 10%左右， 13 亿 * 10% = 1.3 亿）

• 日常日活用户数<业务>：1300 万 （假设日活 10%， 1.3 亿 * 10% = 1300 万）

• 日常日下单数量<业务>：130 万 （假设 10%用户下单， 1300 万 * 10% = 130 万）

• 峰值日活用户数<业务>：7800 万 （假设日活 60%， 1.3 亿 * 60% = 7800 万）

• 峰值日下单量<业务>：1.56 亿 （2 张低额满减优惠卷的加持下，人均 2 单， 7800 * 2 = 1.56 亿）

技术指标转换（技术同学从业务指标中提取推到核心技术指标的关键信息）

• 交易订单日常 TPS<技术>：72 单（假设中午 1 小时和晚上 3 小时占了 80%的订单， 130 万 * 80% / ( 4 * 60 * 60) ≈ 72 单）

• 交易订单日常并发连接数<技术>：14（假设平均创建交易订单 RT 为 200ms，单位换算， 72 * 0.2 ≈ 14 单）

• 履约订单日常 TPS<技术>：16 单（假设仓发货分两个波次，一个中午 12 点，一个下午 6 点，假设晚 6 到中午 12 的订单占了 80%， 130 万 * 80% / ( 18 * 60 * 60) ≈ 16 单）

• 交易订单峰值 TPS<技术>：8 万单（假设 0 点前 5 分钟创建 10%的订单， 1.56 亿 * 10% / ( 5 * 60 ) ≈ 8 万单）

• 交易订单日常并发连接数<技术>：1.6 万（假设平均创建交易订单 RT 为 200ms，单位换算， 8 万单 * 0.2 ≈ 1.6 万）

• 履约订单日常 TPS<技术>： 2528 单（假设仓发货分两个波次，一个中午 12 点，一个下午 6 点，假设晚 0 点到中午 12 的订单占了 70%， 1.56 亿 * 70% / ( 12 * 60 * 60) ≈ 2528 单）

容量预测（技术同学结合压力预测和服务单服务实例容量推导出扩容节点数量）

• 基于上诉压力预估，再结合对服务压测得到的平均单服务实例容量，既可以计算出服务集群节点的数量。

• 交易订单日常节点数 = 交易订单日常并发连接数（14） / 单服务实例最大连接数

• 履约订单日常节点数 = 履约订单日常 TPS（16） * 创建履约订单平均耗时 / 单服务实例最大连接数

• 交易订单峰值节点数 = 交易订单日常并发连接数（1.6 万） / 单服务实例最大连接数

• 履约订单峰值节点数 = 履约订单日常 TPS（2528 单） * 创建履约订单平均耗时 / 单服务实例最大连接数

综上所述，交易侧，大促的峰值并发相较于日常并发有了万倍的提升，并且这个峰值还是均摊了 5 分钟的压力得到的，实际的并发峰值从 0 点开始的 1s 算还会更高，已经达到了几百几千个节点的量级。而供给侧，因为没有直面用户峰值请求的诉求，只要消费速率能赶上每个波次时间点就行，所以只需要看 tps，整体的流量是平稳的，也就不需要太多机器，一般在几个到几十个之间。

短视频案例

假设我们要设计一个国内的短视频应用，就叫中华短视频。目标用户数是中国的人口总数，约为 13 亿人。

中华短视频的核心功能需求非常简单，主要包括用户上传视频、搜索视频和观看视频。在上传视频方面，主要关注上传视频的事务处理能力（TPS）、每秒传输速率（BPS）以及存储空间。搜索视频方面，主要关注视频元信息的查询处理能力（QPS）。而在观看视频方面，则主要关注视频数据的读取速率（BPS）、查询处理能力（QPS）和并发连接数。

业务指标盘点（与业务同学做工作坊的模式）

• 目标用户数<业务>：13 亿

• 系统用户数<业务>： 3 亿（前三年假设初期用户做到 23%左右， 13 亿 * 23% ≈ 3 亿）

• 日活用户数<业务>：1.5 亿 （假设日活 50%， 3 亿 * 50% = 1.5 亿）

• 日观看视频数<业务>：15 亿（假设每个用户每天观看 10 个视频， 1.5 亿 * 10 个 = 15 亿）

• 日搜索次数<业务>：3 亿（假设每个用户每天搜索 2 次， 1.5 亿 * 2 次 = 3 亿）

• 每个短视频平均大小<业务>：50M

• 每个短视频平均时长<业务>：1 分钟

• 每个视频平均播放次数<业务>：500 次

• 视频创作工作者一天工作时间<业务>： 8h

技术指标转换（技术同学从业务指标中提取推到核心技术指标的关键信息）

• 视频文件实际查询处理能力 QPS<技术>：8 万（假设中午 1 小时和晚上 3 小时占了 80%的视频观看次数， 15 亿 * 80% / ( 4 * 60 * 60) ≈ 8 万）

• 并发用户数<技术>：480 万（并发用户数等于同时在观看的视频数，等于 QPS 乘以每个短视频平均时间， 8W * 60 = 480W）

• 并发连接数<技术>：960 万（假设用户采用双线路缓存视频，并发连接数等于并发用户数乘以 2， 480 万 * 2 = 960W）

• 读取视频速率 BPS 大小<技术>： 521Gb（等于 QP 乘以每秒单个视频下载大小， 8 万 * （50M * 8bit / 60） ≈ 521 Gb）

• 视频上传事务数率 TPS<技术>：104 个（等于日观看数除以平均播放次数除以视频创作者工作时间，假设视频创作工作者时间， 15 亿 / 500 次 / (8 * 60 * 60) ≈ 104 个）

• 视频上传每秒传输速率 BPS<技术>： 0.8Gb（等于 TPS 乘以每秒单文件上传大小，假设单个文件每秒传输 2%， 104 个 * （50M * 8 * 2%） ≈ 0.8Gb）

• 日磁盘存储空间大小<技术>：5.6TB（将 BPS 乘以视频工作者一天工作时间，比特换算成字节，同时因为采用副本双写以保证高可用，还需乘以 2， 0.8Gb * （8 * 60 * 60） / 8 * 2 ≈ 5.6TB）

• 视频元信息实际查询速率 QPS<技术>：1.7 万 （假设中午 1 小时和晚上 3 小时占了 80%的查询次数， 3 亿 * 80% / ( 4 * 60 * 60) ≈ 1.7 万）

以上场景不包含，热点视频热点新闻带来的高峰 QPS 和 BPS 的诉求。

容量预测（技术同学结合压力预测和服务单服务实例容量推导出扩容节点数量）

• 视频文件服务节点数 = 并发连接数 / 单服务实例最大连接数

• 半年磁盘扩容大小 = 日磁盘存储空间大小 * 180

• 视频文件服务的总带宽 = 读取视频速率 BPS 大小 / 8

• 视频站内搜索的节点数 = 视频元信息实际查询速率 QPS / (1s /单次查询 RT<200ms> * 单服务实例最大连接数)

综上所述，短视频这种应用因为用户粘性强，在线时间长，所以相对于电商对系统的要求就高了很多。存储空间、带宽、上传下载速率都有了更高的要求。

卖馄饨案例

假设年过 35 被公司裁员了，打算在小区门口摆摊卖混沌，目标用户数是小区人口数，5000。

明天就要出摊了，我需要预估下要准备几张桌子，几份食材以及多少套打包盒。

业务指标盘点（踩点，咨询其他小贩）

• 目标用户数<业务>：2000 人（小区有三个门，最繁华的商业街在东门门人流量大概占了人口数的 40%，我们在这摆摊， 5000 * 40% = 2000）

• 系统用户数<业务>： 600 人（工业区附近的楼房，不做饭的上班族居多，预计会来购买的人数占比 30%， 2000 * 30% = 600 人）

• 日活用户数<业务>：480 人（假设 80%都会规律的来看下， 600 * 80% = 480 人）

• 日购买份数<业务>: 240 份（综合有的早晚各吃一份，有的给家人同事带，以及大部分没买，假设人均购买 0.5 份）

• 堂食的并发用户数<技术>：18 人 （假设早上 1 小时占了 60%的购买量，一半人堂食，每人就坐到吃完差不多 15 分钟， 240 * 60% * 50% * （15 / 60） = 18 人）

容量预测

• 食材份数： 日购买份数

• 打包盒份数： 日购买份数 * 50%

• 桌子数： 堂食的并发用户数 / 4(每张桌子最多坐 4 人)

综上所述，我明儿只需要带 5 张桌子 120 份打包盒就足以应付所有场景的并行压力了，如果我一个人应付得来的话。

小结

笔者试着来总结下这些案例的共性，提炼一些基本的判断标准，和计算规则。

关注用户并发数和并发连接数指标，主要发生在系统需要应对强波动流量或压力峰值的场景。通常出现在用户数量庞大、操作集中、且不能丢失用户请求的场景，如电商双十一零点峰值、短视频热点视频、混沌摊的早高峰等。测算思路为：找出峰值流量的时间段，结合历史数据和用户规模估算这一时间段的事务数或压力大小，并结合单个事务的处理时间来推算可能存在的最大并发连接数。

关注系统的 TPS（事务处理率）、QPS（查询处理率）和 BPS（字节传输率）指标，主要发生在系统需要应对相对稳定的流量或压力，并且没有明显的峰值的场景。一般出现在用户数量较少、操作时间分布均匀、允许丢失用户请求或没有直接用户交互的场景，如短视频上传、电商履约订单拆合单等。预估思路为：结合历史数据和用户规模估算事务数或压力大小，并在允许处理这些事务或流量的时间内均匀分配压力，将单位转换为秒，即可得到相应的吞吐量指标。

压力预估虽然看似内容不多，但想要熟练掌握却颇具挑战。首先，这些判断标准和计算规则仅能提供一定的参考，因为实际情况随着行业、场景不同，指标和预估思路可能都会有所变化。其次，由于参考的指标和预估思路会发生变化，因此需要具备较强的洞见和类比能力，而这些能力需要在大量实践中逐步培养。最后，还存在博弈问题。在预估压力时，考虑到钱并非自己掏的情况下，过度预估可能不会有什么问题，但如果精心测算结果预估偏低，则可能会因此承担责任。因此，在这种博弈条件下，倾向于高估似乎是最优解。

所以，希望每个同学都有我的岗位就是生死之地，我的决策关系存亡之道的敬畏心和责任心。秉着知行合一的态度，在日常工作和生活中不断去尝试基于数据做预估的能力，并结合实际效果，不断思考和调整。最后，希望同学们能先胜于庙堂，不夺胜于战场。不要像张三一样，在巨大压力下去急中生智解决问题。同时，对自己的预估结果添加冗余量是正确的，但要观察实际的压力情况，并在下一次预估中去调整，以此来不断精进自己的预估能力。

在过去的十年里，跑马圈地的时代，成本并不是主导因素，因此精益经营并不显得十分重要。然而，如今随着市场竞争的日益激烈和经济形势的下行，如何以更低的成本实现相同甚至更好的效果已成为企业存活的关键。因此，具备精益经营能力的人才在市场上的价值也在逐步提高，希望同学们能通过这个预估能力的锻炼提高自己精益经营的能力，从而在市场上占据更多的优势。