System Design 101 系统设计速查表：高可用、高吞吐与高扩展的实战方案-平芜编程栈

后端
文档
教程

【免费下载链接】system-design-101

Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.

项目地址：https://gitcode.com/GitHub_Trending/sy/system-design-101

本速查表整理自 data/guides/system-design-cheat-sheet.md，并辅以仓库内相关指南交叉印证。系统设计面试与真实架构评审中，最常被问到的三个核心目标是高可用（High Availability）、高吞吐（High Throughput）、高扩展（High Scalability）。读完本文，你将掌握三者的精确定义与度量方式、达成每个目标的成熟架构方案（冗余模式、缓存策略、扩展路径），并能依据响应时间与可用性指标做出可落地的架构取舍。

一、速查表讲的是什么：三个常被混用的设计目标

在系统设计场景里，我们经常被要求"为高可用、高扩展、高吞吐而设计"。这三个词看似相近，实则对应完全不同的关注点与衡量指标：

设计目标	核心关注点	常用度量
高可用	系统在约定水平上的持续在线能力（uptime）	可用性百分比（"3 nines" / "4 nines"）
高吞吐	单位时间内能处理多少请求	QPS（query per second）、TPS（transaction per second）
高扩展	能否快速、低成本地扩容以容纳更多流量或功能	响应时间、扩容成本曲线

三者在架构上互相配合但并不等同：可用性靠冗余，吞吐靠缓存与并发，扩展靠架构的可伸缩设计。下面分别展开。

二、高可用（High Availability）：用"几个九"说话

2.1 什么是可用性目标

高可用意味着确保系统达到约定级别的高在线时间（uptime）。我们通常用"几个九"来描述设计目标：

"3 nines"：99.9% 在线时间，意味着每天最多约 86.4 秒不可用（每年约 8.76 小时）。
"4 nines"：99.99% 在线时间，意味着每天只能停机 8.64 秒（每年约 52.6 分钟）。

仓库内配套指南 data/guides/how-do-we-design-for-high-availability.md 给出了同样的口径：当设计目标是 4 nines 时，服务一年只能停摆约 52.5 分钟。同时该文档强调了一个容易忽略的边界——可用性只保证"能收到响应"，并不保证返回的数据是最新的，这为后面讨论"最终一致性"埋下了伏笔。

2.2 达成高可用的四类冗余模式

要实现高可用，核心手段是在系统中设计冗余（redundancy）。速查表给出了四种经典模式：

1. Hot-hot（热-热双活）

两个实例接收相同的输入，并把输出同时发给下游服务。当一侧宕机时，另一侧可立即接管，无需切换时间。

关键代价：由于两侧都在向下游发送输出，下游系统必须做去重（dedupe），否则会产生重复数据或重复副作用。

2. Hot-warm（热-温主备）

两个实例接收相同输入，但只有**热（hot）**一侧向下游发送输出；当热侧宕机时，温（warm）侧接管并开始发送输出。

与 hot-hot 相比，下游无需去重，但存在切换延迟窗口。

3. Single-leader cluster（单主集群）

一个 leader 实例从上游接收数据，并复制（replicate）到其他副本（replica）。

这是数据库主从复制（read replica）的经典形态，写集中在 leader，副本可分担读流量。仓库中的 data/guides/read-replica-pattern.md 与 data/guides/how-to-implement-read-replica-pattern.md 对此有更细化的说明。

4. Leaderless cluster（无主集群）

集群中没有 leader，任何写入都会复制到其他实例。只要写入实例数 + 读取实例数 > 总实例数，就总能读到有效数据。

这正是 Dynamo 风格架构与分布式一致性 Quorum 的思想：用"多数派"约束保证读写交集非空。可参考 data/guides/top-eventual-consistency-patterns-you-must-know.md 理解由此带来的最终一致性问题。

2.3 冗余之外：故障容错的配套措施

速查表只给了冗余模式，但要让"4 nines"真正成立，还必须配套故障容错手段。data/guides/a-cheat-sheet-for-designing-fault-tolerant-systems.md 归纳了六项原则，与速查表互为补充：

Replication（复制）：在不同节点/位置保存数据或服务的多份拷贝；
Redundancy（冗余）：为故障预留可随时顶替的额外组件；
Load Balancing（负载均衡）：让流量分散到多台服务器，避免单点成为故障源；
Failover Mechanisms（故障切换）：主组件故障时自动切换到备用组件；
Graceful Degradation（优雅降级）：部分组件失效时，系统降级运行而非整体崩溃；
Monitoring and Alerting（监控告警）：持续观测健康度与性能，对异常及时告警。

另外，data/guides/how-do-we-design-for-high-availability.md 从节点拓扑角度补充了三种架构变体：

Primary-Backup（主备）：备份节点只待命，主节点故障需手动切换，硬件利用率低；
Primary-Secondary（主从）：从节点可承接读请求分担读负载，但复制延迟会导致读到不一致数据；
Primary-Primary（双主）：两节点都支持读写并互相复制，吞吐更高但适用场景有限——若两侧同时更新同一商品，最终状态可能不可预测，需谨慎使用。

该文档还给出了一个直观的量化例子：单节点部署在可用性约 90% 的环境（如 EC2 单机）时，改成双节点架构后可用性可提升至约 99%。

三、高吞吐（High Throughput）：QPS/TPS 与三把板斧

3.1 度量与含义

高吞吐指在给定时间段内处理大量请求的能力，常用指标是：

QPS（Queries Per Second）：每秒查询数；
TPS（Transactions Per Second）：每秒事务数。

吞吐与延迟相互影响：单个请求的延迟越低、并发能力越强，单位时间能处理的总请求数就越高。

3.2 达成高吞吐的常用手段

速查表给出三条路径：

1. 加缓存（Cache）

在架构中加入缓存层，让请求直接返回，避免打到数据库、磁盘等较慢的 I/O 设备。仓库中围绕缓存的纵深资料非常丰富：

data/guides/learn-cache.md 与 data/guides/cache-systems-every-developer-should-know.md 给出缓存体系全景；
data/guides/top-5-caching-strategies.md 与 data/guides/what-are-the-top-caching-strategies.md 介绍缓存读写策略；
data/guides/top-8-cache-eviction-strategies.md 与 data/guides/most-popular-cache-eviction.md 覆盖淘汰策略。

2. 增加线程数（并发）

对于计算密集型任务，增加线程数量可以提升并行度。但注意：线程并非越多越好，过多线程会因上下文切换、锁竞争而反而恶化性能。正确做法是先定位瓶颈，再有节制地扩容并发。

3. 异步处理（Async Processing）

用异步处理把重负载组件从主请求链路中隔离出来，是"隔离重活"的有效手段。典型形态包括消息队列与后台 Worker：

data/guides/types-of-message-queue.md 与 data/guides/explaining-the-4-most-commonly-used-types-of-queues-in-a-single-diagram.md 介绍队列选型；
data/guides/how-do-message-queue-architectures-evolve.md 梳理消息队列架构的演进脉络；
data/guides/top-5-kafka-use-cases.md 与 data/guides/the-ultimate-kafka-101-you-cannot-miss.md 给出以 Kafka 为代表的异步解耦实战。

3.3 吞吐优化的配套细节

高吞吐场景下，还需要配套关注：

负载均衡：将请求分散到多台服务器，避免单机成为瓶颈。负载均衡器从实现上可分为硬件、软件、云厂商托管（如 AWS ELB、Google Cloud Load Balancing、Azure Load Balancer），从协议层次上分为 L4（按 IP/TCP/UDP 端口转发）与 L7（应用层转发），详见 data/guides/what-is-a-load-balancer.md、data/guides/cloud-load-balancer-cheat-sheet.md。
重试策略：分布式与网络环境下瞬态错误不可避免，data/guides/how-do-we-retry-on-failures.md 总结了线性退避、线性抖动退避、指数退避、指数抖动退避四种策略，其中指数抖动退避能最大程度避免"重试风暴"（retry storm）导致的高并发下资源争用。

四、高扩展（High Scalability）：横向与纵向，以及何时扩容

4.1 定义：能"快速且容易"地扩展

高扩展意味着系统可以快速、轻松地扩展以容纳更多流量（横向扩展 horizontal scalability）或更多功能（纵向扩展 vertical scalability）。

横向扩展：增加更多服务器节点，把负载分摊开；
纵向扩展：单点能力或功能的增强。

判断是否需要扩容，通常观察响应时间（response time）：当响应时间开始劣化，说明现有容量接近上限，需要触发扩容。

4.2 扩展的三个瓶颈

data/guides/a-crash-course-on-architectural-scalability.md 进一步剖析了阻碍扩展的三个典型瓶颈，与速查表直接呼应：

集中式组件（Centralized components）：成为单点故障（SPOF），难以水平扩展；
高延迟组件（High latency components）：执行耗时的操作，拖慢整体吞吐；
紧耦合（Tight coupling）：组件相互依赖过强，无法独立伸缩。

因此构建可扩展系统应遵循三条原则：无状态（statelessness）、松耦合（loose coupling）、异步处理（asynchronous processing）。

4.3 八种必知扩展策略

data/guides/8-must-know-scalability-strategies.md 把扩展策略系统化为八条，与速查表形成完整配套：

无状态服务（Stateless Services）：服务不依赖服务器本地状态数据，最易扩展；
横向扩展（Horizontal Scaling）：增加服务器分摊工作负载；
负载均衡（Load Balancing）：用负载均衡器把请求均匀分到多台服务器；
自动伸缩（Auto Scaling）：按实时流量调整资源，实施扩缩容策略；
缓存（Caching）：降低数据库压力，规模化应对重复请求；
数据库复制（Database Replication）：跨多节点复制数据，扩展读操作并提升冗余；
数据库分片（Database Sharding）：把数据分布到多个实例，同时扩展读写；
异步处理（Async Processing）：把耗时、资源密集的任务转移到后台 Worker，为新增请求腾出能力。

其中分片与复制相关主题，可继续阅读 data/guides/a-crash-course-in-database-sharding.md、data/guides/key-concepts-to-understand-database-sharding.md、data/guides/top-4-data-sharding-algorithms-explained.md 与 data/guides/consistent-hashing.md。

五、三者的权衡：可用性、一致性与吞吐的边界

速查表的三节内容彼此独立，但真实架构中它们经常互相牵制，有两个关键边界必须记住：

可用性 ≠ 数据新鲜度：高可用只承诺"有响应"，不承诺"数据最新"。冗余复制引入的复制延迟，正是 data/guides/top-eventual-consistency-patterns-you-must-know.md 中四类最终一致性模式（事件驱动、后台同步、Saga、CQRS）要解决的问题。
线程数 ≠ 吞吐：盲目加线程反而劣化性能，吞吐优化的正确姿势是"先找瓶颈，再定向扩容"，并用异步处理把重活移出主链路。

此外，仓库还提供了更宏观的权衡视角：data/guides/10-system-design-tradeoffs-you-cannot-ignore.md、data/guides/top-5-trade-offs-in-system-designs.md，以及面试向的 data/guides/algorithms-you-should-know-before-taking-system-design-interviews.md，可作为继续深挖的入口。

六、速查表使用方式与仓库定位

本篇速查表在仓库中归属Cloud & Distributed Systems分类（见 data/categories/cloud-distributed-systems.md），其定位是"一页图看懂三大设计目标"，适合在系统设计面试前做快速复习、在架构评审时做方案对齐。仓库通过 scripts/readme.ts（依赖 gray-matter 解析每篇指南的 front matter，按分类与创建时间排序）自动生成 README 目录，每篇指南文件均以title、description、categories、tags等元信息开头（如本文件data/guides/system-design-cheat-sheet.md的 front matter），保证了分类与检索的一致性——这也是搜索引擎与 Agent 能够高效定位本文的前提。

一句话使用建议：面试或评审前，先用本文把"三个九 / QPS / 响应时间"这三组口径说清楚，再按需切入上文的对应专题文档展开细节。这比一上来就堆砌组件更能体现对系统设计的本质理解。