0
点赞
收藏
分享

微信扫一扫

架构与思维 系统容量设计

何为设计容量,从技术上说就是运用一些策略对系统容量进行预估的过程。

数据量、并发量、带宽、注册用户规模、活跃用户规模、在线用户规模、消息长度,图片大小、网盘空间容量,内存CPU容量等。


文章目录

  • ​​1.分析过程​​
  • ​​2.系统容量评估时机​​
  • ​​3.评估的步骤​​
  • ​​4.案例说明​​
  • ​​5.总结​​

1.分析过程

TPS(Transactions Per Second):每秒事务数

QPS(Query Per Second):每秒请求数,QPS其实是衡量吞吐量的一个常用指标,就是说服务器在一秒的时间内处理了多少个请求。

并发数:并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。

峰值QPS计算
原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间
公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

PV(Page View):页面访问量,即页面浏览量或点击量,用户每次刷新即被计算一次

UV(Unique Visitor):独立访客,统计1天内访问某站点的用户数(以cookie为依据)

吐吞量:吞吐量是指系统在单位时间内处理请求的数量

响应时间(RT):响应时间是指系统对请求作出响应的时间,一般取平均响应时间

QPS(每秒查询数)、TPS(每秒事务数)是吞吐量的常用量化指标,另外还有HPS(每秒HTTP请求数)。

QPS(TPS)、并发数、响应时间它们三者之间的关系是:

1、QPS(TPS)= 并发数 / 平均响应时间

2、并发数 = QPS * 平均响应时间

2.系统容量评估时机

  1. 临时的流量变化:比如 618、双11,新年大促搞活动等场景,预估我们的流量会大涨,甚至到原来的数倍。这时候要做好应对的措施。
  2. 初始系统容量评估:假设我们开发了某个系统,这个系统初始上线,我们预估他的容量和负载会是多少。
  3. 容量基数的变化:比如某个系统,他的功能模块越来越多,数据流量越来越大,日活指数越来越高,迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求,这时候我们也要重新评估和扩容。

我们系统容量评估包括数据量、并发量、带宽、CPU、MEMORY、DISK等。

3.评估的步骤

1.分析日总访问量
分析可能的日访问量,一般系统系统都会提供比较真实的访问量数值,基于此,我们需要评估一个活动的访问量;如果是一个新上线的系统,我们也要评估可能的PV、UV值。

产品、运营部门也需要给出可能的访问预期值。

2.评估平均访问量QPS
QPS是每秒请求量,假设我们一天正常活动时间一般是11个小时多一点,那一天的时间长度以秒为单位:606011 ≈ 4W, 我们再使用日访问时间再去除以4W总时间即可.

比如:
我们活动期间(9点~10点)会推送2000W的应用消息,假设用户实际点进去查看的比列为1/10,那么这个活动期间(1小时)新增的访问量就有 2000W * 1/10= 200W

我们上面说的两个小时的活动时间,实际的总访问量最后确实是200W,
那么平均访问量QPS为:200W/(60*60)=555.5 QPS.
一个成熟系统日QPS也可以预估 ,比如 百度首页的日PV数量为 5000W,按照我们说的常规活动时间4W秒算,就是5000W / 4W = 1250 QPS.

3.评估高峰区间的QPS
我们在做系统容量规划时,不仅仅是考虑平均QPS,最重要的是要承受住高峰区间的QPS,这个数据可以根据业务流量监控的曲线和28法则来评估

3.1 业务流量监控的曲线

日均QPS为2900,业务访问趋势图如下图,我们来对峰值QPS做一下预估
架构与思维 系统容量设计_架构
从图中可以看出,峰值QPS大概是均值QPS的2.58倍,日均QPS为2900,于是评估出峰值QPS为2900*2.58=7482。

这种是日常流量情况,如果遇到很特别的业务,比如竞拍\抢订\秒杀情况,流量幅度还是比较大的.

3.2 使用二八法则计算

何为二八法则:80%的业务基本都是发生在20%的时间里面,所以有如下:

峰值QPS公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

4.评估单实例极限承受的QPS
可以使用压测(nGrinder 或者 jmeter)方式来获取单个系统实例的QPS极限值,我们团队的标准是当请求响应时间超过2S的时候,已经达到了瓶颈值,并影响使用,需要进行优化和扩容。

我们在一个系统上线前,一般来说是需要进行压力测试,了解她实际的极限值在哪个地方,以我们上面流量图为例子(日平均QPS为2900,峰值QPS为7500),这个系统的架构可能是这样的:

架构与思维 系统容量设计_响应时间_02

  1. 经由APP和Web的的请求,会经过Nginx均衡到多台Web站点上去。
  2. Web集群会调用并落地到Service集群上
  3. Service集群向数据层请求数据,正常情况下其中90%会落到Cache集群中
  4. Cache集群中不存在(假设10%),会进入DB集群去访问数据库。

web层是瓶颈,tomcat压测单个实例只能支持2500的QPS。
Cache集群和DB集群足够强悍,能够轻松应对峰值7500的QPS,按比例分别是75000.9=6750 和 75000.1=750.

所以我们得到了web单实例极限的QPS是2500。这边需要下调,因为我们不建议让请求响应时长接近2S,最好是1S以内。所以下调至2000。

5.根据线上冗余度最终确认
通过上面的计算,我们已经得到了峰值QPS是7500,单个实例能够顺畅承载QPS是2000,那么Web集群中至少有4个实例能够承接这样的请求洪峰。

除此之外,其他类型的的容量预估,如数据量、带宽、CPU、MEMORY、DISK等都可以采用类似策略。

4.案例说明

架构与思维 系统容量设计_响应时间_03

5.总结

系统设计容量评估时机:

1、临时的流量变化:比如 618、双11,新年大促搞活动等场景,预估我们的流量会大涨,甚至到原来的数倍。这时候要做好应对的措施。

2、初始系统容量评估:假设我们开发了某个系统,这个系统初始上线,我们预估他的容量和负载会是多少。

3、容量基数的变化:比如某个系统,他的功能模块越来越多,数据流量越来越大,日活指数越来越高,迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求,这时候我们也要重新评估和扩容。

系统设计容量评估的步骤:

1、分析日总访问量:产品、运营的评估和线上数据的收集

2、评估日平均访问量QPS:评估运营时间内的平均QPS

3、评估高峰区间的QPS:流量曲线计算 或 28 法则估算

4、性能压力测试:评估实例能够承受的极限吞吐量

5、根据线上冗余度,与实际的差值进行调整,评估出能承载容量的实际结果值

举报

相关推荐

0 条评论