后端文档教程【免费下载链接】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点击查看免费下载这篇指南以 system-design-101 仓库中的 如何扩展网站以支撑百万级用户 文档为核心用一个简化的电商网站作为贯穿案例完整梳理网站从单台服务器上的单体应用演进为面向服务/微服务架构的六步路线图。读完本文你将掌握应用与数据库拆分、集群化与负载均衡、读写分离、数据库分区、缓存层以及微服务化这几大核心扩展手段各自的适用场景、实现细节与代价并能直接用于系统设计面试的口述与架构选型。背景一个简化的电商网站先设定一个具体的案例。假设我们的电商系统包含两个核心业务域库存服务inventory service负责商品描述与库存管理用户服务user service负责用户信息、注册、登录等。扩展的本质是系统在负载增长时仍能保持原有性能。从仓库中的 架构可扩展性速成课 可以看到扩展通常面临三大瓶颈集中式组件Centralized components容易成为单点故障高延迟组件High latency components执行耗时操作拖慢整条链路紧耦合Tight coupling组件互相依赖难以独立扩展。因此可扩展系统的设计原则可以概括为无状态statelessness、松耦合loose coupling、异步处理asynchronous processing。下面六步正是沿着这条主线展开的。Step 1把应用服务器与数据库服务器拆开随着用户量增长第一道坎是一台服务器扛不住全部负载。此时最基础的动作是把应用服务器与数据库服务器分别部署到两台独立机器上应用服务器专职处理请求逻辑、渲染与业务计算数据库服务器专职存储与查询独立分配磁盘 I/O 与内存资源。这一步消除了应用计算与数据库存取争抢同一台机器资源的互相干扰为后续各自独立扩展垂直扩容或水平扩容创造了前提。它是所有后续步骤的地基先分离再扩展。Step 2部署应用服务器集群业务继续增长单台应用服务器再次不够用。此时不再无限堆高单机配置垂直扩展有硬件天花板而是部署一组应用服务器集群让负载在多台实例之间分担——这就是水平扩展horizontal scaling。8 个必知扩展策略 中专门强调了水平扩展的两条配套原则无状态服务stateless services服务不依赖服务器本地保存的会话或业务数据任何一台实例都能处理任意请求这样新增实例即可线性分摊压力水平扩展add more servers通过增加服务器数量共享工作负载而非单纯升级单机。集群出现后下一个问题立刻浮现请求来了该交给哪台服务器Step 3引入负载均衡让流量均匀分发有了多台应用服务器就必须有一个组件把进来的请求均匀路由到它们身上避免某台实例过载、其他实例闲置——这个组件就是负载均衡器load balancer。仓库中的 什么是负载均衡器 给出了完整的能力清单与分类负载均衡器做什么分发流量Distributes traffic保证可用性与可靠性Ensures availability and reliability——配合健康检查自动摘除故障实例提升性能Improves performance让应用得以扩展Scales applications。类型与层次硬件负载均衡专用物理设备分发流量软件负载均衡部署在标准硬件或虚拟机上的应用程序如 Nginx 等云负载均衡云厂商提供的集成式方案例如 AWS Elastic Load Balancer、Google Cloud Load Balancing、Azure Load BalancerL4 负载均衡传输层基于 IP 地址与 TCP/UDP 端口做转发决策性能高、对内容无感知L7 负载均衡应用层工作在 OSI 应用层可按 URL、请求头、Cookie 等内容做更精细的路由GSLB全局服务器负载均衡跨地域分发流量用于全球范围的高可用与就近访问。结合 架构可扩展性速成课 的定义负载均衡把请求分散到多台服务器上防止单台服务器成为瓶颈。注意负载均衡同时也消除了单台应用服务器这一集中式单点呼应了前面提到的第一类瓶颈。Step 4读写分离用读副本扛住读流量业务持续增长数据库开始成为新瓶颈。大多数业务是读多写少的商品浏览、订单查询远多于下单因此一个高性价比的做法是读写分离把频繁的读查询分流到**读副本read replicas**上主库专注写入从而大幅提升数据库整体吞吐。仓库中的 读副本模式 给出了这个模式的完整定义与工作流程所有数据修改命令insert、delete、update都发往主库primary DB读请求则发往读副本。以电商下单为例的典型流程用户下单请求到达订单服务Order Service订单服务在主库写入订单记录数据复制到两个副本用户查看订单详情读请求由副本响应用户查看最近订单历史仍由副本响应。这个模式最大的坑是复制延迟replication lag。在网络延迟、服务器过载等情况下副本中的数据可能落后主库几秒甚至几分钟。如果用户刚下完单立刻去查订单状态、而查询恰好被路由到落后的副本就可能看不到刚下的单体验非常困惑。这需要写后读一致性read-after-write consistency。文档给出的三种缓解方案对延迟敏感的读请求直接发往主库紧跟写操作之后的读请求路由到主库关系型数据库通常提供副本是否追平主库的检测能力副本数据已最新则查副本否则读主库或让该次读请求失败重试。实现方式应用层路由 vs 数据库中间件如何实现读副本模式 介绍了两种落地方式把路由逻辑内嵌到应用代码中应用自己判断读请求走主库还是副本使用数据库中间件——中间件在应用与数据库之间提供透明的路由可基于用户、schema、SQL 语句等规则定制路由逻辑。它通常走标准 MySQL 网络协议因此任何兼容 MySQL 的客户端都能接入迁移成本低。两种方式各有取舍应用内嵌路由实现简单但应用要感知数据库拓扑中间件让应用代码保持简洁、兼容性好但引入了额外的复杂层与网络延迟且由于所有查询都经过它必须做高可用部署以避免单点故障。Step 5单个数据库扛不住时垂直分区 / 水平分区 / 缓存三选一假设业务继续增长单个数据库已经无法同时承受 inventory 表和 user 表的负载。此时原文档给出三个选项选项 A垂直分区Vertical Partitioning给数据库服务器加更多算力CPU、内存等。它的优点是无侵入、见效快但存在硬性上限——单机硬件总有天花板且成本随配置非线性上涨。原文档明确标注it has a hard limit因此它适合作为过渡手段而不是终极方案。选项 B水平分区Horizontal Partitioning / Sharding增加更多数据库服务器把数据分散到多台机器上。垂直分区与水平分区 给出了两种策略的精确定义垂直分区把某些列移到新表每张表行数相同但列更少水平分区常称分片 sharding把一张表切成多张更小的表每张表列数相同但行更少每张表是独立的数据存储。水平分区应用最广关键在于**路由算法routing algorithm**决定数据落在哪个分片基于范围的分片range-based sharding用有序列整数、long、时间戳等切分。例如按 User ID 范围ID 1、2 进 shard 1ID 3、4 进 shard 2基于哈希的分片hash-based sharding对一列或多列做哈希决定归属。例如以User ID mod 2作为哈希函数ID 1、3 进 shard 1ID 2、4 进 shard 2。收益便于水平扩展加机器即扩容量、缩短响应时间查询只需扫更少的行。代价跨分片的 ORDER BY 排序变复杂通常要取回各分片数据在应用层排序、可能出现数据倾斜某些分片数据远多于其他分片即热点 hotspot。这与 8 个必知扩展策略 中分片可同时扩展读写的定位一致。选项 C加缓存层卸载读压力增加缓存层把读请求从数据库卸载出去让高频重复查询直接在内存中命中。仓库中的 5 大缓存策略 列出了引入缓存后与数据库保持同步的常用策略读策略Cache Aside应用先查缓存未命中再查数据库并回填缓存Read Through缓存层自己负责从数据库加载缺失数据。写策略Write Around直接写数据库缓存靠读时回填更新Write Back先写缓存后台异步刷入数据库吞吐高但有丢数据风险Write Through写数据库的同时同步更新缓存一致性最好但写路径更慢。这些策略常组合使用例如Write Around 常与 Cache Aside 搭配保证缓存不会长期脏数据。一个值得注意的定位区别分区B解决的是数据太多单机装不下/写不动的容量问题缓存C解决的是读请求太频繁的性能问题。两者并不互斥在实践中往往叠加使用——缓存顶住读热点分片摊开写与容量。Step 6模块化拆分走向面向服务 / 微服务架构最后一步把单体应用内部的函数按业务域模块化拆分成不同的服务架构由此演进为面向服务service-oriented或微服务microservice。回到开头的案例即库存服务与用户服务成为独立部署、独立扩展的单元。这一步的价值与配套原则可以结合仓库相关文档理解每个服务拥有独立的生命周期与扩容策略——比如用户量暴涨时只需单独扩 user service而不是整体扩容服务间通过 API 通信实现松耦合可独立演进与故障隔离从 8 个必知扩展策略 看微服务化之后应继续贯彻异步处理async processing把耗时、资源密集的任务如发邮件、生成报表挪到后台 worker 异步执行让新请求能快速得到响应避免被长任务阻塞。需要注意的是微服务并非银弹它引入了服务发现、API 网关、分布式事务、可观测性等一系列新的复杂度。它应被看作扩展演进的阶段结果而不是起点——先有清晰的业务边界与稳定的接口契约再谈拆分。总结六步扩展路线图把整条演进路线浓缩成一张速查表也是系统设计面试时最常被要求的从 0 到 1 扩展系统的标准答题骨架步骤触发条件核心动作解决的核心问题参考文档Step 1单机负载过高拆分应用服务器与数据库服务器资源互相争抢扩展网站Step 2单应用服务器不足部署应用服务器集群吞吐容量不足8 个必知扩展策略Step 3多实例流量分配引入负载均衡器流量不均、单点故障什么是负载均衡器Step 4数据库成瓶颈主从复制 读写分离读吞吐不足读副本模式、如何实现读副本模式Step 5单库容量/写压力见顶垂直分区、水平分区、加缓存层容量与读压力垂直分区与水平分区、5 大缓存策略Step 6单体难以独立演进模块化拆分为面向服务/微服务独立扩展与故障隔离扩展网站面试要点提示回答如何扩展到百万级用户这类问题时按 Step 1 → Step 6 的顺序逐步演进每步都说明为什么当前架构撑不住了 这步做了什么 引入了什么新问题比直接抛出微服务方案更能体现工程判断力。同时记住贯穿全程的三条原则服务无状态、组件松耦合、耗时任务异步化它们是任何一层扩展方案背后的通用逻辑。如果想继续深入某一环仓库中还有 数据库扩展的 7 大必知策略、一致哈希、缓存系统如何用 与 消息队列类型 等专题文档可以衔接阅读。赞分享后端文档教程【免费下载链接】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点击查看免费下载相关推荐从单机到千万级用户system-design-primer 的 AWS 架构扩展实战指南从单机到千万级用户system design primer 的 AWS 架构扩展实战指南 本篇以 system design primer https://l文档教程后端从单机到千万用户在 AWS 上设计可扩展系统system-design-primer 实战方案解析从单机到千万用户在 AWS 上设计可扩展系统system design primer 实战方案解析 本文以 system design primer 仓库文档教程后端Flax NNX 辅助组件实战解析Sequential / List / Dict / TrainState 的使用与源码原理Flax NNX 辅助组件实战解析Sequential / List / Dict / TrainState 的使用与源码原理 Flax NNX 是 Flax后端文档教程上一篇xberg C FFI 实战用 xberg_extract_batch 一次批量提取多个内存字节文档下一篇Kimi Code CLI 环境变量完全指南数据路径、模型切换、遥测控制与代理配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考