系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
目录
1 何时需要进行容量评估
- 容量有质变性增长
- 临时运营活动
- 新系统上线
两个场景例子：
- 要做双十一促销活动，那么机器能不能抗住，扛不住有需要加几台
- 新系统上线，数据库需不需要分库，如果需要，那么分几个库
技术上来说，这些都是系统容量预估问题，容量设计是架构师的必备技能。
2 哪些指标需要进行容量预估
看具体业务侧的主要矛盾是什么：
- 数据量 （通常有用户发布行为的，如帖子）
- 并发量、吞吐量 （抢票、秒杀）
- 带宽（音视频）
- CPU/MEM/DISK等（计算需求、IO密集）
3 架构设计的容量评估步骤（吞吐量为例）
1 评估总访问量
方式： 询问产品、运营的预期访问量是多少
Q： 一个App-push的运营活动，计划在30min内完成5000w用户的push推送，预计push点击率为10%，那么push落地页的总访问量是多少？
A： 5000w * 10% = 500w
2 评估平均访问量
QPS的计算方式为：总量 / 时间，若以一天计，则当作为4w秒。
QPS、并发、吞吐等的理解可以参考这篇文章：QPS、TPS、吞吐量等性能指标的理解
Q： push落地页系统30min的访问量为500w，平均QPS为多少？
A： 500w / （30 * 60）
Q： 某信息分类网站的日均PV约8000w，平均QPS是多少？
A： 一天按照4w秒计算，8000w / 4w = 2000
3 评估高峰QPS
方式
- 根据业务的访问曲线图来，按照比例计算峰值QPS
- 没有曲线图则根据82原则计算，认为80%的请求落在20%的时间里，即（总量*0.8）/ （总时间*0.2）
访问曲线图：
若日均QPS为2000，则根据图中得到平均和峰值的比例关系为1：2.5，那么峰值的QPS可以估计为500
4 评估系统、单机极限QPS
方式： 进行压力测试
举例，以App-push运营活动落地页为例（日均2000QPS，峰值5000QPS）假设系统的架构如下：
- 访问端是APP
- 活动的落地页是一个H5
- H5的数据大部分来自cache（99%），少数来自db（1%）
通过压力测试发现，web层是瓶颈，tomcat的压测只能抗住1200QPS
5 根据线上冗余度做决策
经过上面4个步骤的计算，已经得到了需求的容量大小，再根据线上已经有的，就可以判断出是否需要能够满足需求，以及扩容到什么程度。
举例： 若线上有两台web服务器，那么为了满足需求应至少再增加三台，四台更为保险。
在上述的五个步骤中，只有第四步压力测试是需要提前准备的，其它四步骤都是临时计算得到的。
下一篇要讨论的是快速解决单机资源瓶颈的实践方案，伪分布式与垂直拆分，以及它们又引入了什么新问题。
上一篇回顾：【成为架构师1-2】技术选型：框架组件要不要自研，何时自研
下一篇更精彩：【成为架构师2-2】伪分布式与垂直拆分：快速解决单机性能问题的实践方案