[TOC]

如何评估、预测系统的QPS

容量评估按照5倍冗余计算

系统架构设计背景

当我们在设计一套系统的时候，我们要考虑好系统的架构设计、模块划分、技术方案选型、还有系统性能如能够承受的QPS。当我们线上系统能够支撑10W QPS的时候，我们要考虑100W QPS的架构优化、当我们系统能够支撑100W的时候，我们要思考1000W的架构优化和改进。同时，经验告诉我们，从10W到100W再到1000W一定不是理所当然的线性增长。

为啥要提前预估线上的最大QPS，因为这样我们才能做到白盒化，才能做到心中有数，才能提前有一定的方案，但是这个方案不一定要马上实施，作为技术人员，方案是一定需要有的，什么时候实施，如何时候是另外一回事。

本文就如何评估、预测我们系统的QPS做一些经验输出，不足之处望大佬们指正~

评估案例和方案

为啥要进行评估？因为不同的QPS，所带来的挑战是不同的，架构设计也是不一样的

如何评估系统的QPS

如何评估系统的QPS，指的是我们的系统支撑的业务场景需要满足的一个最大承压，对于一个新项目而言，一般来说，有这样几个方式：

1. 产品和运营人员告诉你，我们这个系统上线，日活达到多少、同时在线达到多少、总用户将会有多少等等，这个是产品和运营对这个新项目的预估

   • 这个是一个参考数据，不能全信也不可不信

2. 凭借自身已有的经验进行预估，如一个视频聊天的产品的预估、如一个社交产品的预估、如一个微博系统的预估等等。

社交、视频聊天的预估

对于视频聊天，我们可以这样预估QPS：

1. 预估平均每个用户每天30次视频匹配、 15次视频聊天
2. 预估每个用户每天30分钟视频时间，峰值为平均QPS的3-4倍，一天时间24h

不同日活的不同数据：

• 10w*30分钟 * 4 / 24h = 0.83w QPS
• 100W*30分钟 * 4 / 24h = 8.3w QPS

目前是预估30分钟，但是后面爆款后，这个时长可能变化很大，需要预留一定的流量，并且百万日活，并不是仅仅是100w，300w-400w内，都算百万日活，因此，在此基础上，还要再有3-4倍的量。

Feed系统的预估

对于Feed这样的系统（如微博），我们可以预估一下，全量用户每天总共会发送1000W条Feed，那么Feed子系统一天就会产生1000W条消息，同时，我们预估每条Feed平均有10个用户会去查看，也就是要读取这条消息，因此读取消息就是1亿次。

这也是一天的总量，那么QPS如何算呢？

• 写： 1000W / 24 h = 115.7 QPS
• 读： 115.7 * 10 = 1157 QPS

按照上面的推论，峰值为平均QPS的3-4倍，那么实际的QPS应该是：

• 写： 1000W / 24 h * 4 = 463 QPS
• 读： 115.7 * 10 * 4 = 4630 QPS

同时为了应对高峰，和后续的增长，我们的QPS肯定要在现有基础上再进行一些扩充，一般还是3-4倍余量。因此，最终我们预估：

• 写： 1000W / 24 h * 4 * 4 = 1852 QPS
• 读： 115.7 * 10 * 4 * 4 = 18520 QPS

这里的3-4倍不是一定的，但是是根据实际经验的一个参考值，不同的业务会有不同的倍数。

如何预测系统的QPS

在预测系统的QPS前，我们需要有一些已知的经验型数据，如日志QPS在6-10w、 RPC的QPS在 10W ，Redis的QPS是8-10w，MySQL大致6k-1W。以上是大体范围，不同机器不同配置有不同结果。

抛开其他的不谈，我们需要看看，我们一次请求调用，有多少次写日志、多少次读写底层资源、多少次RPC调用，然后取其中最低的个值，这是我们预测系统能够达到的最大值。

然而，我们压测的目的在于验证我们的猜测，看看我们实际系统和预测的有多少差别。这就是为什么有经验的人只要你告诉他你的系统架构设计，他就能预估你的系统最大能承受的QPS是多少的原因。

在实际应用中，我按照此种方式去预测和压测，发现压测的值和预测的值，相差比较小，当然压测数据一定是小于预测数据的。这就说明系统设计的还算ok。