单位每年都会举行运动会，有一个2000m长跑的项目，大约每年报名人员为男选手40人，女选手20人，只有一条橡胶跑道。一次比赛10人齐跑，所以至少需要6场比赛。
2000米的完成时间要求是20分钟，超过20分钟不计数，所以比赛耗时我们计算为20分钟，加上比赛前的动员组织，比赛后的清场，我们假定每场比赛耗时30分钟。
现在我们预估下耗时：
1、60人/10人每场 = 6场，至少需要举行6场
2、总耗时 = 6场 * 0.5h = 3h
所以每年把这个比赛安排在下午3点到6点，是最后一个比赛项目，晚上7点举行颁奖晚会。这个预估容量也算合理。
但是今年比较特别，取消了4000米的长跑，所以2000米报名人员激增50人。时间还是下午3点到6点，
这个就有问题了，最后为了保证晚会的正常进行，一半的人员的比赛时间推迟到另外一周的周末，搞得怨声四起，大骂举办的行政部门不讲武德。
这个是我们单位真实的故事，这就是设计容量，当你的业务场景的容量发生了变化时候，没有预估到他的变化，以及变化可能产生的影响，没有按照这个影响及时的做调整
（比如将比赛时间提前，拉长整个比赛的过程时间，或者增加比赛跑到，同时进行两场比赛），就会造成灾难。
概念何为设计容量，从技术上说就是运用一些策略对系统容量进行预估的过程。容量设计是架构师必备的技能之一。
他要求我们分析系统设计容量要求，尽可能给出具体数据描述的：数据量、并发量、带宽、注册用户规模、活跃用户规模、在线用户规模、消息长度，图片大小、网盘空间容量，内存CPU容量等。
下面的内容，我们以 并发 为例子，看看看具体的分析过程。
分析过程 理解一些原理TPS（Transactions Per Second）：每秒事务数
QPS（Query Per Second）：每秒请求数，QPS其实是衡量吞吐量的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求。
并发数：并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
峰值QPS计算：
1、原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
2、公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次
UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数(以cookie为依据)
吐吞量：吞吐量是指系统在单位时间内处理请求的数量
响应时间（RT）：响应时间是指系统对请求作出响应的时间，一般取平均响应时间
QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。
QPS（TPS）、并发数、响应时间它们三者之间的关系是：
1、QPS（TPS）= 并发数 / 平均响应时间
2、并发数 = QPS * 平均响应时间
系统容量评估时机主要在三种业务场景下需要及时考虑对系统容量进行评估。
1、临时的流量变化：比如 618、双11，新年大促搞活动等场景，预估我们的流量会大涨，甚至到原来的数倍。这时候要做好应对的措施。
2、初始系统容量评估：假设我们开发了某个系统，这个系统初始上线，我们预估他的容量和负载会是多少。
3、容量基数的变化：比如某个系统，他的功能模块越来越多，数据流量越来越大，日活指数越来越高，迎来了第二波的增长曲线。我们原来定好的系统容量渐渐的不满足我们的需求，这时候我们也要重新评估和扩容。
我们系统容量评估包括数据量、并发量、带宽、CPU、MEMORY、DISK等。以并发量为案例，我们来说明系统容量评估的方法和步骤。
评估的步骤 1、分析日总访问量分析可能的日访问量，一般系统系统都会提供比较真实的访问量数值，基于此，我们需要评估一个活动的访问量；如果是一个新上线的系统，我们也要评估可能的PV、UV值。