单位每年都会举行运动会,有一个2000m长跑的项目,大约每年报名人员为男选手乾隆年号40人,女选手20人,只有一条橡胶跑道。一次比赛10人齐跑,所以至少需要6场比赛。
2000米的完成时间要求是20分钟,超过20分钟不计数,所以比赛耗时我们计算为20分钟,加上比赛前的动员组织,比赛后的清场,我们假定每场比赛耗时30分钟。
现在我们预估下耗时:
1、60人/10人每场 = 6场,至少需要举行6场
2、总耗时 = 6场 * 0.5h = 3h
所以每年把这个比赛安排在下午3点到6点,是最后一个比赛项目,晚上7点举行颁奖晚会。这个预估容量也算合理。
但是今年比较特别,取消了4000米的长跑,所以2000米报名人员激增50人。时间还是下午3点到6点,
这个就有问题了,最后为了保证晚会的正常进行,一半的人员的比赛时间推迟到另外一周的周末,搞得怨声四起,大骂举办的行政部门不讲武德。
这个是我们单位真实的故事,这就是设计容量,当你的业务场景的容量发生了变化时候,没有预估到他的变化,以及变化可能产生的影响,没有按照这个影响及时的做调整
(比如将比赛时间提前,拉长整个比赛的过程时间,或者增加比赛跑到,同时进行两场比赛),就会造成灾难。
何为设计容量,从技术上说就是运用一些策略对系统容量进行预估的过程。容量设计是架构师必备的技能之一。
他要求我们分析系统设计容量要求,尽可能给出具体数据描述的:数据量、并发量、带宽、注册用户规模、活跃用户规模、在线用户规模、消息长度,图片大小、网盘空间容量,内存cpu容量等。
下面的内容,我们以并发为例子,看看看具体的分析过程。
tps(transactions per cond):每秒事务数
qps(query per cond):每秒请求数,qps其实是衡量吞吐量的一个常用指标,就是说服务器在一秒的时间内处理了多少个请求。
并发数:并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。
1、原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间
2、公式:( 总pv数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(qps)
pv(page view):页面访问量,即页面浏览量或点击量,用户每次刷新即被计算一次
uv(unique visitor):独立访客,统计1天内访问某站点的用户数(以cookie为依据)
吐吞量:吞吐量是指系统在单位时间内处理请求的数量
响应时间(rt):响应时间是指系统对请求作出响应的时间,一般取平均响应时间
qps(每秒查询数)、tps(每秒事务数)是吞吐量的常用量化指标,另外还有hps(每秒http请求数)。
qps(tps)、并发数、响应时间它们三者之间的关系是:
1、qps(tps)= 并发数 / 平均响应时间
2、并发数 = qps * 平均响应时间
主要在三种业务场景下需要及时考虑对系统容量进行评估。
1、临时的流四川有什么大学量变化:比如 618、双11,新年大促搞活动等场景,预估我们的流量会大涨,甚至到原来的数倍。这时候要做好应对的措施。
2、初始系统容量评估:假设我们开发了某个系统,这个系统初始上线,我们预估他的容量和负载会是多少。
3、容量基数的变化:比如某个系统,他的功能模块越来越多,数据流量越来越大,日活指数越来越高,迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求,这时候我们也要重新评估和扩容。
我们系统容量评估包括数据量、并发量、带宽、cpu、memory、disk等。以并发量为案例,我们来说明系统容量评估的方法和步骤。
分析可能的日访问量,一般系统系统都会提供比较真实的访问量数值,基于此,我们需要评估一个活动的访问量;如果是一个新上线的系统,我们也要评估可能的pv、uv值。
产品、运营部门也需要给出可能的访问预期值。
举个例子:
我们活动期间(9点~10点)会推送2000w的应用消息,假设用户实际点进去查看的比列为1/10,那么这个活动期间(1小时)新增的访问量就有 2000w * 1/10= 200w
qps是每秒请求量,假设我们一天正常活动时间一般是11个小时多一点,那一天的时间长度以秒为单位:60*60*11 ≈ 4w, 我们再使用日访问时间再去除以4w总时间即可.
举个例子:
我们上面说的两个小时的活动时间,实际的总访问量最后确实是200w,
那么平均访问量qps为:200w/(60*60)=555.5 qps.
一个成熟系统日qps也可以预估 ,比如 百度首页的日pv数量为 5000w,按照我们说的常规活动时间4w秒算,就是5000w / 4w = 1250 qps.
我们在做系统容量规划时,不仅仅是考虑平均qps,最重要的是要承受住高峰区间的qps,这个数据可以根据业务流量监控的曲线和28法则来评估,我们来看下具体是怎么做的?
以下面这个云系统作为例子:
日均qps为2900,业务访问趋势图如下图,我们来对峰值qps做一下预估
从图中可以看出,峰值qps大概是均值qps的2.58倍,日均qps为2900,于是评估出峰值qps为2900*2.58=7482。
这种是日常流量情况,如果遇到很特别的业务,比如竞拍\抢订\秒杀情况,流量幅度还是比较大的.
何为二八法则:80%的业务基本都是发生在20%的时间里面,所以有如下:
峰值qps公式:( 总pv数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(qps)
可以使用压测(ngrinder 或者 jmeter)方式来获取单个系统实例的qps极限值,我们团队的标准是当请求响应时间超过2s的时候,已经达到了瓶颈值,并影响金口玉言的意思使用,需要进行优化和扩容。
我们在一个系统上线前,一般来说是需要进行压力测试,了解她实际的极限值在哪个地方,以我们上面流量图为例子(日平均qps为2900,峰值qps为7500),这个系统的架构可能是这样的:
1、经由app和web的的请求,会经过nginx均衡到多台web站点上去。
2、web集群会调用并落地到rvice集群上
3、rvice集群向数据层请求数据,正常情况下其中90%会落到cache集群中
4、cache集群中不存在(假设10%),会进入db集群去访问数据库。
我们通过压测数据发现,web层是瓶颈,tomcat压测单个实例只能支持2500的qps。
cache集群和db集群足够强悍,能够轻松应对峰值7500的qps,按比例分别是7500*0.9=6750 和 7500*0.1=750.
所以我们得到了web单实例极限的qps是2500。这边需要下调,因为我们不建议让请求响应时长接近2s,最好是1s以内。所以下调至2000。
通过上面的计算,我们已经得到了峰值qps是7500,单个实例能够顺畅承载qps是2000,那么web集群中至少有4个实例能够承接这样的请求洪峰。
除此之外,其他类型的的容量预估,如数据量、带宽、cpu、memory、disk等都可以采用类似策略。
结合项目:如何计算图书系统的qps、峰值qps、n个实例和并发数
1、图书预定系统的并发数计算:
1.1、二八法则定理:80%的业务基本都是发生在20% 的时间里面,如系统有早中晚高峰,历经9个小时(早上10点到晚上19点),9*3600=32400。
1.2、获取峰值qps:公式:( 总pv数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(qps)
即 ( 1500000 * 80% ) / ( 32400 * 20% ) = 600000/6480≈185/秒
1.3、并发数 = qps 新文化运动的意义* 平均响应时间 = 0.5*185 = 92.5 ,矫正为100
1.4、利用343估算法判定 154,向上矫正为200
pessimism 悲观
30%
80
normal 标准
40%
100
optimism 乐观
30%
300
最后提供给性能测试qa 的测试标准数据是 建议支持并发 200+,qa最终的测试结果是 该并发下响应时间在 50~100ms
1、临时的流量变化:比如 618、双11,新年大促搞活动等场景,预估我们的流量会大涨,甚至到原来的数倍。这时候要做好应对的措施。
2、初始系统容量评估:假设我们开发了某个系统,这个系统初始上线,我们预估他的容量和负载会是多少。
3、容量基数的变化:比如某个系统,他的功能模块越来越多,数据流量越来越大,日活指数越来越高,迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求,这时候我们也要重新评估和扩容。
1、分析日总访问量:产品、运营的评估和线上数据的收集
2、评估日平均访问量qps:评估运营时间内的平均qps
3、评估高峰区间的qps:流量曲线计算 或 28 法则估算
4、性能压力测试:评估实例能够承受的极限吞吐量
5、根据线上冗余度,与实际的差值进行调整,评估出能承载容量的实际结果值
显然,开头的运动会如果子报名结束后能够根据报名的人数对比,重新做容量设计,提早做好准备,情况就不会那么糟糕。
以上就是架构与思维论设计容量的重要性的详细内容,更多关于架构思维设计容量重要性的资料请关注www.887551.com其它相关文章!
本文发布于:2023-04-04 21:16:46,感谢您对本站的认可!
本文链接:https://www.wtabcd.cn/fanwen/zuowen/463b8ac2c1a26094d53f1f1d1dcf3e97.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文word下载地址:架构与思维论设计容量的重要性.doc
本文 PDF 下载地址:架构与思维论设计容量的重要性.pdf
留言与评论(共有 0 条评论) |