[TOC]
如何评估、预测系统的QPS
容量评估按照5倍冗余计算
系统架构设计背景
当我们在设计一套系统的时候，我们要考虑好系统的架构设计、模块划分、技术方案选型、还有系统性能如能够承受的QPS。当我们线上系统能够支撑10W QPS的时候，我们要考虑100W QPS的架构优化、当我们系统能够支撑100W的时候，我们要思考1000W的架构优化和改进。同时，经验告诉我们，从10W到100W再到1000W一定不是理所当然的线性增长。
为啥要提前预估线上的最大QPS，因为这样我们才能做到白盒化，才能做到心中有数，才能提前有一定的方案，但是这个方案不一定要马上实施，作为技术人员，方案是一定需要有的，什么时候实施，如何时候是另外一回事。
本文就如何评估、预测我们系统的QPS做一些经验输出，不足之处望大佬们指正~
评估案例和方案
为啥要进行评估？因为不同的QPS，所带来的挑战是不同的，架构设计也是不一样的
如何评估系统的QPS
如何评估系统的QPS，指的是我们的系统支撑的业务场景需要满足的一个最大承压，对于一个新项目而言，一般来说，有这样几个方式：
-
产品和运营人员告诉你，我们这个系统上线，日活达到多少、同时在线达到多少、总用户将会有多少等等，这个是产品和运营对这个新项目的预估
- 这个是一个参考数据，不能全信也不可不信
-
凭借自身已有的经验进行预估，如一个视频聊天的产品的预估、如一个社交产品的预估、如一个微博系统的预估等等。
社交、视频聊天的预估
对于视频聊天，我们可以这样预估QPS：
- 预估平均每个用户每天30次视频匹配、 15次视频聊天
- 预估每个用户每天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。
网友评论