单位每年都会举行运动会，有一个2000m长跑的项目，大约每年报名人员为男选手40人，女选手20人，只有一条橡胶跑道。一次比赛10人齐跑，所以至少需要6场比赛。
现在我们预估下耗时：
1、60人/10人每场=6场，至少需要举行6场
2、总耗时=6场*0.5h=3h
所以每年把这个比赛安排在下午3点到6点，是最后一个比赛项目，晚上7点举行颁奖晚会。这个预估容量也算合理。
这个是我们单位真实的故事，这就是设计容量，当你的业务场景的容量发生了变化时候，没有预估到他的变化，以及变化可能产生的影响，没有按照这个影响及时的做调整
何为设计容量，从技术上说就是运用一些策略对系统容量进行预估的过程。容量设计是架构师必备的技能之一。
他要求我们分析系统设计容量要求，尽可能给出具体数据描述的：数据量、并发量、带宽、注册用户规模、活跃用户规模、在线用户规模、消息长度，图片大小、网盘空间容量，内存CPU容量等。
下面的内容，我们以并发为例子，看看看具体的分析过程。
TPS（TransactionsPerSecond）：每秒事务数
并发数：并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
PV（PageView）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次
UV（UniqueVisitor）：独立访客，统计1天内访问某站点的用户数(以cookie为依据)
QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。
主要在三种业务场景下需要及时考虑对系统容量进行评估。
1、临时的流量变化：比如618、双11，新年大促搞活动等场景，预估我们的流量会大涨，甚至到原来的数倍。这时候要做好应对的措施。
2、初始系统容量评估：假设我们开发了某个系统，这个系统初始上线，我们预估他的容量和负载会是多少。
3、容量基数的变化：比如某个系统，他的功能模块越来越多，数据流量越来越大，日活指数越来越高，迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求，这时候我们也要重新评估和扩容。
我们系统容量评估包括数据量、并发量、带宽、CPU、MEMORY、DISK等。以并发量为案例，我们来说明系统容量评估的方法和步骤。
分析可能的日访问量，一般系统系统都会提供比较真实的访问量数值，基于此，我们需要评估一个活动的访问量；如果是一个新上线的系统，我们也要评估可能的PV、UV值。
产品、运营部门也需要给出可能的访问预期值。
举个例子：
我们活动期间(9点~10点)会推送2000W的应用消息，假设用户实际点进去查看的比列为1/10，那么这个活动期间(1小时)新增的访问量就有2000W*1/10=200W
那么平均访问量QPS为:200W/(60*60)=555.5QPS.
我们在做系统容量规划时，不仅仅是考虑平均QPS，最重要的是要承受住高峰区间的QPS，这个数据可以根据业务流量监控的曲线和28法则来评估,我们来看下具体是怎么做的
以下面这个云系统作为例子：
日均QPS为2900，业务访问趋势图如下图，我们来对峰值QPS做一下预估
从图中可以看出，峰值QPS大概是均值QPS的2.58倍，日均QPS为2900，于是评估出峰值QPS为2900*2.58=7482。
这种是日常流量情况,如果遇到很特别的业务,比如竞拍\抢订\秒杀情况,流量幅度还是比较大的.
我们在一个系统上线前，一般来说是需要进行压力测试,了解她实际的极限值在哪个地方，以我们上面流量图为例子（日平均QPS为2900，峰值QPS为7500），这个系统的架构可能是这样的：
1、经由APP和Web的的请求，会经过Nginx均衡到多台Web站点上去。
2、Web集群会调用并落地到Service集群上
3、Service集群向数据层请求数据，正常情况下其中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、图书预定系统的并发数计算：
即(1500000*80%)/(32400*20%)=600000/6480≈185/秒
1.4、利用343估算法判定154，向上矫正为200
Pessimism悲观
30%
80
Normal标准
40%
100
Optimism乐观
300
1、分析日总访问量：产品、运营的评估和线上数据的收集
3、评估高峰区间的QPS：流量曲线计算或28法则估算
4、性能压力测试：评估实例能够承受的极限吞吐量
5、根据线上冗余度，与实际的差值进行调整，评估出能承载容量的实际结果值
显然，开头的运动会如果子报名结束后能够根据报名的人数对比，重新做容量设计，提早做好准备，情况就不会那么糟糕。