容量评审材料包含三项内容：①预计明年线上客户增长40%；②订单服务在高峰期95%请求应在2秒内完成；③数据库连接池峰值使用率已达85%。三项内容按顺序更接近（）。
客户和交易增长属于业务需求预测；端到端订单服务响应目标属于服务能力；连接池是支撑服务的具体技术资源，属于组件容量。
选项分析
错误。把业务预测和技术组件的位置颠倒了。
正确。业务量、服务性能和技术资源分别对应三层容量分析。
错误。客户增长不是服务指标，连接池也不是业务需求。
错误。三项都属于容量管理的不同观察层次，不是三个互不相关的管理过程。
本题为什么容易错
看到“客户数量”也有人直接想到数据库容量，但考试更看重推导链。客户增长是输入，订单负载是中间转换，连接池需求才是技术结果。
简短答案
用户增长、订单响应和数据库连接池，分别属于哪一层容量分析，正确答案是 B（业务容量、服务容量、组件容量）。客户和交易增长属于业务需求预测；端到端订单服务响应目标属于服务能力；连接池是支撑服务的具体技术资源，属于组件容量。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 组件容量、业务容量、服务容量 | 本题干扰项 | 错误。把业务预测和技术组件的位置颠倒了。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 业务容量、服务容量、组件容量 | 本题正确答案 | 正确。业务量、服务性能和技术资源分别对应三层容量分析。 | 看到题干核心场景时优先联想到它 |
| 服务容量、组件容量、业务容量 | 本题干扰项 | 错误。客户增长不是服务指标，连接池也不是业务需求。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 可用性管理、事件管理、财务管理 | 本题干扰项 | 错误。三项都属于容量管理的不同观察层次，不是三个互不相关的管理过程。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 组件容量、业务容量、服务容量：错误。把业务预测和技术组件的位置颠倒了。
- 服务容量、组件容量、业务容量：错误。客户增长不是服务指标，连接池也不是业务需求。
- 可用性管理、事件管理、财务管理：错误。三项都属于容量管理的不同观察层次，不是三个互不相关的管理过程。
知识点详解
容量管理不能只做服务器监控。业务容量关注业务计划、用户数、交易量和产品变化；服务容量关注端到端吞吐、响应时间和服务等级；组件容量关注计算、存储、网络、中间件、连接池等资源。三层数据结合后，团队才能解释“为什么要扩容、扩哪里、何时扩”，并在扩容后验证服务目标是否真正改善。
备考速记
业务看需求，服务看体验，组件看资源；从外到内算容量。
容量管理在容量管理场景中的作用
如果明年用户增长40%，订单峰值不一定机械增长40%，还要考虑人均下单频次、活动集中度和缓存命中率。容量模型要把业务假设显式写出来，才能在假设变化时重新计算。
同类题怎么考
- 把容量指标归入业务、服务或组件层。
- 根据业务增长推导服务吞吐和基础资源需求。
容量管理在系统规划与管理师软考中的考法
题目给客户数、销售量或业务计划，先归业务层；给端到端响应和吞吐，归服务层；给CPU、连接、磁盘或带宽，归组件层。
解题思路
这题用“从外到内”最好判断。先看业务要增长多少，再看用户实际使用的服务需要达到什么性能，最后才落到连接池、CPU、存储和带宽。客户增长是外层业务，订单响应是中间服务，连接池是内部组件，因此选 B。
考点定位
业务容量回答未来业务会有多大，服务容量回答端到端服务能否承受，组件容量回答具体技术资源是否足够。三层要能相互追溯。
易错提醒
- 只监控CPU平均值，没有把资源变化关联到订单量和响应目标。
- 业务部门修改增长计划后，容量模型没有同步更新。
- 服务总体达标，却忽略某个组件已接近饱和且扩容周期很长。
备考提示
- 画三层漏斗：业务预测到服务负载，再到组件资源。
- 给每一层各准备两个指标，避免只会背定义。
你可能还想了解
- 业务容量和组件容量有什么区别？
- 响应时间属于哪一层容量指标？
- 容量规划为什么不能只看CPU？
本文小结
客户增长属于业务容量，订单响应目标属于服务容量，数据库连接池属于组件容量。三层共同形成从业务需求到技术资源的推导链。