本页面探讨了系统设计中性能和可伸缩性之间的根本区别。理解这些概念对于设计能够处理增长同时保持响应性的系统至关重要。有关延迟和吞吐量的相关主题，请参阅延迟与吞吐量。
性能和可伸缩性虽然相关，但它们解决了系统高效处理工作的不同方面。
如果一个服务能够随着资源的增加而按比例提升性能，那么它就是可伸缩的。通常，提升性能意味着处理更多的工作单元，但也可以是处理更大的工作单元，例如当数据集增长时。
性能问题与可伸缩性问题的明确区分
垂直伸缩涉及向现有机器添加更多计算能力。虽然概念上简单，但这种方法有其局限性。
水平伸缩将负载分布到多台机器上，实现了几乎无限的增长潜力，但需要架构上的改变。
在设计性能和可伸缩性时，您必须识别并解决潜在的瓶颈
| 组件 | 性能瓶颈 | 可伸缩性瓶颈 | 解决方案方法 |
|---|---|---|---|
| 应用程序 | 低效算法、阻塞操作 | 线程争用、并发性不足 | 优化代码、使用异步处理 |
| 数据库 | 慢查询、索引不佳 | 锁竞争、连接限制 | 索引、查询优化、连接池 |
| 存储 | I/O 密集型操作 | 磁盘容量、IOPS 限制 | 缓存、CDN、SSD、分片 |
| 网络 | 延迟、带宽 | 连接限制、饱和 | 压缩、协议优化、CDN |
| 内存 | 内存不足、垃圾回收 | 高单请求内存使用 | 内存优化、缓存策略 |
来源：README.md703-713 README.md1083-1273
在解决可伸缩性挑战时，选择垂直伸缩还是水平伸缩取决于您的具体需求
| 方面 | 垂直伸缩 | 水平伸缩 |
|---|---|---|
| 实现 | 向现有服务器添加更多资源（CPU、RAM、磁盘） | 添加更多服务器来分担负载 |
| 复杂性 | 较低，实现更简单 | 较高，需要架构调整 |
| 成本 | 初始成本较高，高端硬件昂贵 | 单位成本较低，使用通用硬件 |
| 限制 | 硬件限制，单点故障 | 理论上无限，网络可能成为瓶颈 |
| 停机时间 | 通常需要停机才能升级 | 无需停机即可完成 |
| 用例 | 用户群有限、有特殊硬件需求的应用程序 | Web 服务、分布式应用程序、可变工作负载 |
| 状态管理 | 更简单的状态管理（所有内容都在一台机器上） | 需要分布式状态管理、会话共享 |
设计能够同时处理性能和可伸缩性问题的应用程序需要平衡多个因素
来源：README.md413-420 README.md703-713
性能测试与可伸缩性测试不同
| 性能测试 | 可伸缩性测试 |
|---|---|
| 侧重于响应时间和资源使用情况 | 侧重于负载增加时的行为 |
| 使用一致的、受控的负载 | 逐渐增加负载直到系统崩溃 |
| 指标：响应时间、延迟、错误率 | 指标：吞吐量、性能下降点 |
| 工具：性能分析器、APM 工具 | 工具：负载生成器、分布式测试框架 |
| 示例：“我们能否在 100 毫秒内处理此事务？” | 示例：“我们可以支持多少并发用户？” |
在设计系统时，您通常需要在优化单用户性能与多用户可伸缩性之间进行权衡
为实现良好的性能和可伸缩性
来源：README.md413-420 README.md703-713 README.md941-951
理解性能和可伸缩性之间的区别是有效系统设计的基础。性能问题导致系统对单个用户来说很慢，而可伸缩性问题则在高负载下显现。理想情况下，系统应通过仔细的架构设计、测试和持续改进来有效处理这两个方面。
请记住，一切都是权衡。通常，过度优化单用户性能可能会使伸缩变得更加困难，而高度分布式的可伸缩系统可能会引入影响基线性能的开销。