单位每年都会举行运动会，有一个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其实是衡量吞吐量的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求。