产品上线或者线上运营活动如何进行容量估计

场景一： PM近期要举行很大的运营活动，技术大佬过来，询问：

1. 机器能抗住不？
2. 是否需要进行扩容，得扩多少？

场景二：产品要上线，技术大佬过来问

1. 咱们这得多少资源？
2. 现在资源够不？

上面所说的都是系统容量预估的问题，容量预估一般包括：数据量、并发量、带宽、CPU、MEM和磁盘等

1.并发量

1.1 总访问量评估

  如何知道总访问量，这个就要和询问业务同事、运营同事、以及产品同事，对于产品上线或者运营活动的预期
  例如：
      需要做个APP-Push活动，计划在30分钟内完成5000w用户的推送，预计点击率为10%，那么PV量，则为
       5000W*5%=500W

1.2 平均访问量QPS

如何知道平均访问量QPS？
QPS=总量/时间
假如时间以天评估，24小时60分钟60秒=8w秒，假设所有请求都发生在白天，那么一天只按照4w秒评估

举例1：push落地页系统30分钟的总访问量是500w，求

平均访问量QPS： 500w/(30*60) = 2778，大概3000QPS

举例2：主站首页估计日均pv 8000w，求

平均访问QPS：一天按照4w秒算，8000w/4w=2000，大概2000QPS

1.3 峰值

如何知道峰值呢，峰值需要根据业务访问的曲线进行评估，
举例：日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？

回答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。

1.4 评估单机极限QPS

答案是：压力测试
在一个服务上线前，一般来说是需要进行压力测试的（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：
1）访问端是APP
2）运营活动H5落地页是一个web站点
3）H5落地页由缓存cache、数据库db中的数据拼装而成
通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。一般来说，线上系统是不会跑满到极限的，cpu最大跑到%80，单机线上允许跑到QPS1000。

1.5 根据实际线上冗余度回答两个问题

步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，那么
1）机器能抗住么？ -> 峰值5000，单机1000，线上2台，扛不住
（2）如果扛不住，需要加多少台机器？ ->需要额外3台，提前预留1台更好，给4台更稳

2.带宽

如何评估带宽？
首先需要知道影响带宽的因素有哪些？

• 数据包大小
• 部署方式
• 通信链路

2.1 数据包大小

数据包的大小可以取得到实际的业务数据包大小的平均值

2.2 部署方式

   如果是直连模式，那么带宽可能需要乘以2，当然还有旁路模式，这个就得具体考虑部署架构

2.3 通信链路

  可能需要和部分业务系统之间都有交互，而且都是通过同一张网卡，那么该节点的带宽肯定占用较大

3. 内存和CPU

如何估算内存和CPU呢？
在这里为什么把内存和CPU放在一块呢？因为内存和CPU其实要根据压测效果来讲，因为这些都涉及系统调优之后，根据压测结果，进行估算。
例如：压测时，10000qps，8C16G单机cpu压到80%，内存消耗8G
那么当qps达到50000时，那么就需要至少5台这样设备组成集群，或者单机最少配置分配到40C80G.

磁盘

 磁盘的估算，需要根据业务系统的需要进行分配
 比如：该业务系统每秒的日志产生量为50G, 需要本地保留10分钟的日志，也就是日志落盘量为50G*600=30T左右，那么磁盘最起码得分配到30T