★ FEATURED ARTICLE 后端文档教程【免费下载链接】system-design-101Explain 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高吞吐单位时间内能处理多少请求QPSquery per second、TPStransaction per second高扩展能否快速、低成本地扩容以容纳更多流量或功能响应时间、扩容成本曲线三者在架构上互相配合但并不等同可用性靠冗余吞吐靠缓存与并发扩展靠架构的可伸缩设计。下面分别展开。二、高可用High Availability用几个九说话2.1 什么是可用性目标高可用意味着确保系统达到约定级别的高在线时间uptime。我们通常用几个九来描述设计目标3 nines99.9% 在线时间意味着每天最多约 86.4 秒不可用每年约 8.76 小时。4 nines99.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 ThroughputQPS/TPS 与三把板斧3.1 度量与含义高吞吐指在给定时间段内处理大量请求的能力常用指标是QPSQueries Per Second每秒查询数TPSTransactions 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用异步处理把重负载组件从主请求链路中隔离出来是隔离重活的有效手段。典型形态包括消息队列与后台 Workerdata/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 / 响应时间这三组口径说清楚再按需切入上文的对应专题文档展开细节。这比一上来就堆砌组件更能体现对系统设计的本质理解。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐EnergyBar深度评测为什么它是Mac Touch Bar的最佳替代方案EnergyBar深度评测为什么它是Mac Touch Bar的最佳替代方案 EnergyBar是一款能够为Mac Touch Bar带来全新生命力的实用工具system-design-101 可扩展性指南8 大必备扩展策略与系统设计实践system design 101 可扩展性指南8 大必备扩展策略与系统设计实践 本篇指南以仓库 8 must know scalability strate后端文档教程System Design 101从零构建高性能报表系统架构的完整指南System Design 101从零构建高性能报表系统架构的完整指南 在当今数据驱动的时代报表系统作为业务决策的核心工具其架构设计直接影响企业的数据分析后端文档教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
