电商总结(六)系统容量预估

  前几天聊过,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, 消息队列,缓存,数据库 等等一系列组成的复杂集群。在分布式系统中,任何节点出现瓶颈,都有可能导致雪崩效应,最后整个集群垮掉 (“雪崩效应”指的是系统中一个小问题会逐渐扩大,最后造成整个集群宕机)。所以,要了解规划整个平台的容量,就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。

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