系统容量预估

Posted 2023-03-30

参考技术A

业务系统往往会被问到一些资源的问题，需要多少机器，机器足不足以支撑当前的业务增长等，这些都是系统容量的一些估算问题。

容量设计需要考虑的维度： 业务规划 + 架构复杂度 + 组件模块 + 高可用 + 安全 + 存储复杂度

容量指标：单机QPS，峰值，平均值，用户数、并发、稳定性

有多少数据量，数据维度有哪些，服务业务有哪些，数据增长预想如何等

这里我们只是谈谈简单的业务通过单节点处理的情况（当然接入网关的处理能力又取决于后端的服务集群的处理能力这里先忽略）

8小时总访问量：1万用户 * 10%的常驻访问率 * 15秒上报周期（每分钟访问4次，每天按照8小时计算）得出日访问量 200万 ~2000万 QPS ： 200~2000万 / 8 * 60 * 60 ≈ 100 ~ 700 QPS

并发数 = QPS * 平均响应时间，假设平均响应时间=100ms，那么100~700 * 0.1 ≈ 10 ~ 70

并发数 =（200~2000万/ 8 / 3600）* 影响因子（一般为3）来进行估算并发量。≈ 200~ 2000

最终得出结论，1万量车每15秒上报一次数据。只需要支持 100左右并发处理能力即可了。

如果单节点服务器的QPS是1000，那么一台机器就能满足 1万台车的数据上报。

常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，

以并发量为例，通过五个步骤，解答业务的疑虑。

对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，问业务部门获得。 例如一个推送活动：计划10分钟，推送1000w用户，10%的消息点击率 那么系统的访问量：1000w * 10% = 100w。10分钟会有100w的访问。

总量除以总时间，如果按照天评估，白天12小时大概4w秒 100w / 30*60 ≈ 600QPS 说明系统需要支持至少 600QPS的访问能力持续10分钟。

需要根据业务访问趋势图预估，可能非常大，暂定为2.5倍

600 * 2.5 = 1500QPS

假设我们的单节点访问能力优化到 1000QPS （tomcat压测单机只能抗住1200的QPS 不能打满打八折 QPS1000）

五个确认步骤

这里我们讨论个场景问题：如果有如下需求，我们应该如何满足业务 一、100万用户秒杀10个商品 二、1秒杀支持1000笔交易

所以从技术角度上系统应该如何做好限流、并发安全、资源弹性。就能初步的评估需要多少资源能满足业务了。 那么我们再来分析下上面两个业务需求。 提取下关键信息：100万用户、库存10个商品、业务时间要求1秒。 我们可以得出两个维度的信息

显然第二个是不太合适的。因为缺少单位时间的业务量，只有用户数。所以如果想要完成评估，单位时间的业务要求才是基础考虑要素。 一个简单的方案：网关层满足限流能力，支持10QPS的处理能力，那么需要增加一台机器即可。剩下的100万用户都访问拒绝，缓冲队列只支持10个用户进入。

如有不对欢迎指正，感谢阅读。

计算公式：
100W个用户，95%均为日活设备即95W
950000 0.8/（3 60 60）=70/s
.70 5=350 即活跃设备数在每秒为350个

100万个设备，日活占12.5%，用2/8原则来估算并发用户数，即80%的用户数会在高峰期点餐，一共5个小时
平均并发用户数C=125000 5 0.8/5 60=1666
并发用户数峰值C`=1666+3 根号 1666=1788

1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3*根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值

QPS和并发量
QPS（q） ：每秒处理的请求数量 并发量 （c）：同时支持多少个用户在线。与服务器的请求处理模型有关，如果是BIO模型，则并发量就受限于最大能支持多少个线程，如果是NIO模型，则并发量与socket连接数相关 平均响应时间（t）：单位为毫秒
他们之间的关系是 q = （1000/t）* c

单台机器的QPS为1000QPS，并发为200

电商总结系统容量预估

　　前几天聊过，pv 和并发 的概念，也大概解释了 并发，带宽等指标的计算。感兴趣的朋友，可以看看我前面那篇文章：《聊一聊PV和并发》。今天再来聊一聊容量预估。

 

　　电商公司的朋友，，这样的场景是否似曾相识：

　　　  运营和产品神秘兮兮的跑过来问：

　　　　我们晚上要做搞个促销，服务器能抗住么？如果扛不住，需要加多少台机器？

　　　　于是，技术一脸懵逼。

 

　　其实，这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。所谓，容量预估其实说白了就是，系统在down掉之前，所能承受的最大流量。这个事技术人员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、CPU,内存 ,磁盘等一系列内容。今天就来聊一聊容量预估的问题。

 　　

　　一，几个重要参数

　　　　  QPS：每秒钟处理的请求数

       　　 并发量： 系统同时处理的请求数

        　　响应时间：  一般取平均响应时间

　　　　 很多人经常会把并发数和QPS 混淆，理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS = 并发量 / 平均响应时间

 

　　二，容量评估的步骤与方法

　　　　1：预估总访问量

　　　　如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？

　　　　最简单的办法就是：询问业务方，询问运营同学，询问产品同学，看产品和运营对此次活动的流量预估。

　　　　不过，业务方对于流量的预估，应该就两个指标，pv 和 用户访问数。技术人员 需要更具这两个数据，计算其他相关指标，比如  QPS 等。具体如何计算可参照我前面一篇 pv和并发 的文章。 

 

　　　　2：预估平均QPS

　　　　　　总请求数 = 总PV * 页面衍生连接数

　　　　　　平均QPS = 总请求数 / 总时间

　　　　　　比如：活动落地页1小时内的总访问量是30w pv，该落地页的衍生连接数为30  ,那么落地页的平均QPS

　　　　　　(30w * 30) /(60 * 60) = 2500， 

 

　　　　3：预估峰值QPS

　　　　　　系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何评估峰值QPS呢？

　　　　　　这个要根据实际的业务评估，通过以往的一些营销活动的 pv 等数据进行预估。一般情况，峰值QPS大概是均值QPS的3-5倍，日均QPS为1000，于是评估出峰值QPS为5000。

 　　　　　　不过，有一些业务例如“秒杀业务”比较难评估业务访问量，这类业务的容量评估不在此讨论。

 

　　　　4：预估系统、单机极限QPS

　　　　　　如何预估一个业务，一个服务器单机的极限QPS呢？

　　　　　　这个性能指标，是服务器，最基本的指标之一，所以没有其他的办法，就是压力测试。通过压力测试，算出服务器的单机极限QPS 。

　　　　　　在一个业务上线前，一般都需要进行压力测试（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP 推送 某营销活动为例（预计 日均QPS 1000，峰值QPS 5000），业务场景可能是这样的：

　　　　　　1）通过 APP 推送一个活动消息 

　　　　　　2）运营活动H5落地页是一个web站点

　　　　　　3）H5落地页由缓存cache、数据库db中的数据拼装而成

 

　　　　　　通过压力测试发现，web 服务器 单机只能抗住1200的QPS，cache和数据库db 能抗住并发压力，（一般来说，1%的流量到数据库，数据库120 QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，这里假设cache不是瓶颈），这样，我们就得到了web单机极限的QPS是1200。一般来说，生产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上允许跑到QPS 1200 * 0.8 = 960 。

　　　　　　扩展说一句，通过压力测试，已经知道web层是瓶颈，则可针对web 相关的做一些调整优化，以提高web 服务器 的单机QPS 。

　　　　　　还有，压力测试工作中，一般是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS。

 

　　　　5：回答最开始那两个问题　　　　　

　　　　　　需要的机器  = 峰值QPS / 单机极限 QPS 

　　　　　　好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：

　　　　　　（1）服务器能抗住么？ -> 峰值5000，单机1000，线上3台，扛不住

　　　　　　（2）如果扛不住，需要加多少台机器？ -> 需要额外2台，提前预留1台更好，给3台保险

 　　三，最后

　　　　   需要注意的是，以上都是计算单个服务器或是单个集群的容量，实际生产环境是由web, 消息队列，缓存，数据库 等等一系列组成的复杂集群。在分布式系统中，任何节点出现瓶颈，都有可能导致雪崩效应，最后整个集群垮掉 （“雪崩效应”指的是系统中一个小问题会逐渐扩大，最后造成整个集群宕机）。所以，要了解规划整个平台的容量，就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。

　　　　　以上，只是个人一些经验分享，有啥不对的地方，大伙轻点拍砖，有更好的建议欢迎回复，，