系统容量预估

系统容量预估

 

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

 

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

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

　　　　咱们晚上要作搞个促销，服务器能抗住么？若是扛不住，须要加多少台机器？

　　　　因而，技术一脸懵逼。

 

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

电商总结

电商总结

电商总结（六）系统容量预估

摘要: 前几天聊过，pv 和并发 的概念，也大概解释了 并发，带宽等指标的计算。感兴趣的朋友，能够看看我前面那篇文章：《聊一聊PV和并发》。今天再来聊一聊容量预估。 电商公司的朋友，，这样的场景是否似曾相识： 运营和产品神秘兮兮的跑过来问： 咱们晚上要作搞个促销，服务器能抗住么？若是扛不住，须要加多少台机器 阅读全文

posted @  2016-09-07 08:51 章为忠 阅读(611) |  评论 (2)  编辑

 

电商总结（五）移动M站建设

摘要: 最近在一直在搞M站，也就是移动web站点。因为是第一次，也遇到了不少问题，因此把最近了解到的东西总结总结。聊一聊什么是移动M站，它有啥做用和优点。 也有人会问，M站和APP有什么不一样？ 1. APP 直接在用户的移动设备上，曝光率相对较高。 而M站需打开浏览器，输入地址才能访问，因此曝光率相对较低。 阅读全文

posted @  2016-04-18 18:32 章为忠 阅读(728) |  评论 (9)  编辑

 

电商总结（四）基于共享存储的图片服务器架构

摘要: 在当前这个互联网的时代，无论何种网站，对图片的需求量愈来愈大，尤为在电商网站中，几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构，扩展，升级的过程当中，确定也会碰到各类各样的问题，各类各样的需求。固然这并不表明，就必须得弄一个特别NB的图片服务架构，简单，高效，稳定就行。因此 阅读全文

posted @  2016-03-08 18:29 章为忠 阅读(1128) |  评论 (14)  编辑

 

电商总结（三）构建数据库的主从架构

摘要: 这段时间，一直在总结电商系统的相关基础技术和架构，写了不少东西。可是仍是发现一个很重要，很基础的方面没有讲到，那就是数据库读写分离的主从架构。可能发展到大型成熟的公司以后，主从架构已经落伍了，取而代之的是更加复杂的数据库集群。可是做为一个小型电商公司，数据库的主从架构应该是最基础的。任何大型的系统架 阅读全文

posted @  2016-03-03 18:24 章为忠 阅读(2305) |  评论 (25)  编辑

 

电商总结（二）日志与监控系统的解决方案

摘要: 前一篇文章聊到了小型电商网站的系统架构，而后有朋友问我，里面的日志与监控指的是啥，因此，今天就来聊聊这个问题。 监控系统主要用于服务器集群的资源和性能监控以及应用异常和性能监控，日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性没必要我多说，总而言之就一句话，只有实时了解 阅读全文

posted @  2016-02-24 18:21 章为忠 阅读(2065) |  评论 (7)  编辑

 

电商总结（一）小型电商网站的架构

摘要: 又是一年年末了，这一年，从传统软件行业进入到电商企业，算是一次转行了吧。刚开始，以为电商网站没有什么技术含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来而已。然而，真正进入到这个行业以后，才发现并非这样。记得有人说过，好的架构，是演化出来的。电商网站的架构也是如此，如今牛逼的电商网站，看似 阅读全文

posted @  2016-02-01 18:21 章为忠 阅读(3561) |  评论 (21)  编辑

 　　

　　一，几个重要参数

　　　　  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台保险

 　　三，最后

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

 

做者：章为忠 
出处：http://www.cnblogs.com/zhangweizhong/