后端文档教程【免费下载链接】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 仓库中《Top 7 Most-Used Distributed System Patterns》一文所列的七个模式Ambassador、Circuit Breaker、CQRS、Event Sourcing、Leader Election、Publisher/Subscriber、Sharding为主线结合仓库内数十篇配套图解文档逐一拆解每个模式的动机、工作原理、适用场景与权衡帮助读者在系统设计面试与真实架构中快速定位该用哪个模式、为什么、怎么用。为什么要关注分布式系统模式模式是经过验证的、可复用的架构方案。在单体应用中进程内方法调用即可解决大多数问题而一旦系统拆分为多节点、多服务、多数据中心我们就必须面对三类全新问题失败是常态正如 弹性模式 一文指出的大型事故通常由某个微小错误引发滚雪球效应最终拖垮整个系统状态需要协调数据分散在多台机器上如何读写、如何同步、如何保证一致性服务需要沟通服务之间如何解耦、如何传递事件、如何避免级联故障。下文七个模式正是围绕这三类问题展开的高频解法。它们通常不会单独出现理解每个模式的适用边界与组合方式才能真正发挥价值。1. Ambassador请求进出的大使代理核心思想Ambassador大使模式指在应用进程之外部署一个代理proxy容器代表应用访问外部服务。它是 Kubernetes 生态中典型的 sidecar边车容器形态业务容器只管业务逻辑而负载均衡、TLS 终止、鉴权、日志、熔断、限流等横切关注点全部下沉到大使容器。与代理模式的关系要理解 Ambassador可以先看仓库中 代理与反向代理 一文对两种代理的定位正向代理Forward Proxy位于用户设备与互联网之间用于保护客户端、规避访问限制、屏蔽特定内容反向代理Reverse Proxy接受客户端请求转发给后端 Web 服务器并把结果返回给客户端用于保护服务器、负载均衡、缓存静态内容、加解密 SSL 通信。Ambassador 本质上是一类贴着应用部署的反向代理它拦截本服务对外部依赖的所有出站流量也常承载入站流量把本来散落在业务代码中的网络健壮性逻辑集中管理。典型职责清单职责说明服务发现与负载均衡动态解析外部服务地址按策略分发请求TLS 终止与加解密统一管理证书业务代码无需处理 HTTPS 细节认证与鉴权在边界统一校验令牌、签名防止敏感逻辑进入业务代码可观测性统一收集请求日志、指标、追踪信息故障隔离在代理层实现熔断、重试、限流避免依赖故障扩散收益与代价收益语言无关、部署无关业务团队可以独立升级代理而不改动应用所有服务获得一致的网络行为基线代价每实例多一个容器意味着更多资源开销与运维复杂度引入额外的网络跳数。2. Circuit Breaker给下游故障装一个断路器核心思想Circuit Breaker熔断器模式借鉴家庭电路中的空气开关当下游服务连续失败达到阈值时熔断器跳闸后续请求不再真实打到下游而是快速失败或走降级逻辑经过一段冷却时间后熔断器进入半开状态放行少量探测请求验证下游是否恢复成功则闭合、失败则再次跳闸。为什么要熔断弹性模式 一文列举了 8 种降低故障损伤的云设计模式超时Timeout、重试Retry、熔断Circuit breaker、限流Rate limiting、削峰Load shedding、舱壁Bulkhead、背压Back pressure、让它崩溃Let it crash并强调这些模式通常组合使用。熔断器的独特价值在于阻止级联失败若一个服务对下游的调用无脑重试下游已经过载时只会雪上加霜。熔断器通过快速失败让故障局部化同时配合超时防止线程长期阻塞与重试只在适当阶段重试形成完整防线。状态机与关键参数状态行为关键参数闭合Closed请求正常放行统计失败率失败阈值、滑动窗口时长打开Open请求快速失败不触达下游冷却/休眠时间半开Half-Open放行少量探测请求探测请求数量、超时实现熔断器通常需要一个滑动窗口内的失败计数/失败率、状态切换的阈值配置、以及打开状态下对调用方的降级响应缓存、默认值、错误提示。与其他弹性模式配合熔断 超时超时防止单个请求悬挂熔断防止系统性过载熔断 重试只对幂等操作重试且重试必须穿过熔断状态机的约束熔断 舱壁Bulkhead舱壁为不同依赖分配独立的线程池/连接池一个依赖打满不影响其他依赖与熔断互补。3. CQRS读写分离让查询与命令各取所需核心思想CQRSCommand Query Responsibility Segregation命令查询职责分离是一种将**读模型查询与写模型命令**彻底分离的架构模式。写入侧使用面向业务规则优化的模型与存储读取侧则使用面向查询性能优化的模型与存储可以是不同的表、不同的数据库甚至不同的技术栈。为什么需要 CQRS仓库 数据管理模式 一文对 CQRS 的定位是分离读与写的数据结构允许各自独立优化从而改善性能、可扩展性与安全性——尤其在读、写需求差异极大的复杂系统中价值突出。现实中的典型场景写路径需要强一致的事务与复杂的业务校验而读路径往往需要高性能的聚合查询、全文检索、报表统计。如果二者共用同一模型往往两头不讨好要么写模型被大量重查询拖慢要么查询被迫为写入的数据结构做昂贵转换。工作方式命令Command改变系统状态的写操作走写模型执行校验、事务与业务规则查询Query不改变状态的读操作走读模型可自由采用物化视图、索引表、缓存、搜索引擎等优化手段同步机制写模型产生的数据变更需要同步到读模型可借助事件或 CDC见下文 Event Sourcing 与 CDC 部分。与相关模式的组合CQRS 物化视图Materialized View读模型可以建立在预计算好的物化视图上复杂聚合不再逐次实时计算见 数据管理模式 中对物化视图的描述数据实际计算并落盘存储显著加速数据仓库与 BI 场景下的查询CQRS 事件溯源写侧以事件日志为源读侧投影Projection出各种专用视图——这是领域驱动设计社区最常见的组合。收益与代价收益读写可以独立扩展读多写少时可单独扩容读侧查询模型可按读模式自由优化写侧安全边界更清晰代价系统复杂度显著上升需要维护读写模型的同步强一致场景下存在延迟窗口属于最终一致性的典型应用详见仓库 你必须知道的最终一致性模式 的梳理该文同时讨论了 CQRS 与相关一致性模式的关系。4. Event Sourcing不存状态只存发生了什么核心思想Event Sourcing事件溯源颠覆了传统 CRUD 的持久化范式不再保存实体的当前状态而是把导致状态变化的所有事件按顺序追加写入一个只追加append-only的事件日志。事件日志就是事实来源source of truth当前状态可以通过重放事件推导出来。与普通 CRUD 设计的差异事件溯源系统设计差异 一文指出事件溯源范式用于设计**具备确定性determinism**的系统它改变了普通系统设计的基本哲学。以电商下单支付为例普通 CRUD直接更新订单表的状态字段已创建 → 已支付旧状态被覆盖丢失Event Sourcing追加OrderPlaced、PaymentReceived等事件订单当前状态由这些事件推导且历史永远可回溯。三大典型落地场景如何将事件溯源融入系统 一文给出了三个极具代表性的案例《纽约时报》把自 1851 年以来的文章、图片与署名全部存进事件存储原始数据再反规范化denormalize成不同视图喂给多个 ElasticSearch 节点支撑网站搜索——历史存档与多视图投影的完美示范CDC变更数据捕获CDC 连接器从数据库表中拉取变更并转换为事件推入 Kafka其他 sink 从 Kafka 消费事件——事件溯源思想与流式管道的结合微服务连接器购物车服务产生加购/移出购物车等事件Kafka 充当事件存储欺诈服务、计费服务、邮件服务各自消费事件——因为事件是事实来源每个服务可以自行确定自己的领域模型服务间实现数据级解耦。与 CDC 的关系变更数据捕获实时数据的关键 一文把 CDC 的流程拆为五步数据变更 → 变更捕获监控事务日志→ 变更处理转换成下游格式→ 变更传播发布到消息队列→ 实时集成sink 连接器消费并更新目标系统。典型的 CDC 方案是 Debezium Kafka Connect KafkaDebezium 为 MySQL、PostgreSQL、Oracle 等主流数据库提供连接器。CDC 让事件溯源思想得以零侵入地接入既有关系型数据库——用户只需关心业务写入其余步骤全部透明。收益与代价收益完整审计轨迹每一次变更都留痕可随时重建任意历史状态支持事件重放、回滚与调试天然适配 CQRS 的投影模型代价事件日志无限增长需要快照Snapshot压缩事件模式演化schema evolution需要版本管理最终一致性带来的查询延迟。5. Leader Election让分布式集群选出一个话事人核心思想很多分布式协调问题——谁是主节点、谁负责写入、谁调度任务——本质上都需要从一群等价节点中选出一个 Leader。Leader Election领导者选举提供一种机制让集群在 Leader 故障后自动选出新 Leader从而保证系统持续可用。与心跳、仲裁的关联分布式系统节点故障检测 一文梳理了六种心跳机制其中与选举关系最密切的是带仲裁Quorum的心跳在 Paxos、Raft 这类一致性协议中心跳用于建立与维持仲裁——只有大多数majority节点在线系统才能做出决策这直接决定了 Leader 是否可以安全履职。其他心跳机制同样服务于选举健康度评估基于推送的心跳节点周期性发信号超时即判失败——实现简单但网络拥塞可能造成误判基于拉取的心跳中心监控定期拉取状态——流量更小但故障发现延迟更高带健康检查的心跳心跳携带 CPU、内存、应用指标——信息更丰富但开销更大带时间戳/带确认的心跳用于区分存活与网络延迟、验证双向链路可用。典型选举流程所有节点启动后以随机超时竞争 Leader如 Raft 中的选举超时赢得选举的节点持续通过心跳宣告我是 LeaderFollower 若在超时时间内收不到 Leader 心跳便发起新一轮选举配合仲裁规则只有获得多数节点支持才能当选避免脑裂split brain下出现多个 Leader。收益与代价收益单点故障自愈系统高可用写入路径清晰只有 Leader 处理写代价选举协议实现复杂Raft/Paxos 皆为经典难题Leader 切换期间存在短暂不可用窗口仲裁要求集群规模为奇数以规避平票。6. Publisher/Subscriber发布订阅让生产者与消费者彻底解耦核心思想Publisher/Subscriber发布/订阅是一种异步消息传递模式发布者不直接调用具体消费者而是把消息发布到主题Topic/代理Broker订阅者按兴趣订阅主题由代理负责扇出fan-out投递。发布者不知道订阅者是谁、有多少个订阅者也无需关心消息从哪来。与队列的对比理解发布订阅前先看仓库 一图看懂四种常用队列 的梳理队列类型特性典型场景简单 FIFO 队列先进先出队尾插入、队头取出按支付响应顺序发送邮件通知环形队列Ring Buffer尾部连头部内存中极快LMAX 低延迟环形缓冲交易组件间通信优先级队列基于堆max/min heap取最高/最低优先级急诊室按病情严重度分配患者双端队列Deque头尾皆可插入删除支持 FIFO 与 LIFO实现栈结构传统点对点队列中一条消息只被一个消费者消费竞争消费而 Pub/Sub 的核心差异是一条消息可被多个订阅者各消费一份——这是事件广播、数据扇出的基础。在仓库案例中的位置Pub/Sub 贯穿仓库多个真实案例CDC 管道Debezium 把数据库变更写入 KafkaTopic多个 sink数据仓库、分析平台、Redis 缓存作为订阅者各取所需见 CDC 一文事件溯源微服务购物车服务发布事件到 Kafka欺诈、计费、邮件服务分别订阅各自维护领域模型见 事件溯源融入系统。关键设计考量投递语义至少一次at-least-once、至多一次at-most-once、恰好一次exactly-once各有代价需按业务容忍度选择顺序性Kafka 等代理以分区partition为单位保证分区内有序跨分区不保证全局有序背压与积压消费者慢于生产者时需通过批量消费、扩容分区等手段消化积压结合弹性模式中的背压思想。收益与代价收益发布者与订阅者生命周期解耦天然支持一对多广播与异步削峰代价消息可能丢失或重复需幂等消费链路延迟增加消息中间件本身成为新的高可用依赖。7. Sharding把数据切开摊到多台机器上核心思想Sharding分片也叫水平分区把一张超大的表/数据集按分片键切分成多份每份shard存放在不同数据库服务器上所有分片合起来构成完整数据集。分片是分布式存储与数据库横向扩展的基石。为什么需要分片数据库分片速成课 一文总结了三大动机单机数据量太大一台数据库服务器能容纳的数据有上限单机请求太多一台服务器能承受的请求量有上限查询延迟升高数据增长导致单表查询越来越慢。核心概念分片键与分片算法分片键Sharding Key是决定数据分布到哪个分片的列分片算法根据分片键计算归属。四大分片算法 一文梳理了四类主流算法算法原理优势/注意点基于范围Range-Based按值域切分如按姓氏字母、按日期区间实现简单、范围查询友好但可能数据倾斜热点基于哈希Hash-Basedshard_id hash(shard_key) % num_shards分布更均匀需选好哈希函数避免碰撞一致性哈希Consistent Hashing哈希环上顺时针找节点增删节点只影响邻近数据减少增删分片时的数据搬迁量详见下虚拟桶Virtual Bucket数据→虚拟桶→物理分片的两级映射重平衡灵活数据移动少此外分片速成课 还提到了目录式分片Directory-Based用一张查找表目录维护分片键到分片位置的映射。一致性哈希详解一致性哈希 一文对比了朴素哈希的痛点serverIndex hash(key) % N在集群规模固定时表现良好但一旦新增或下线服务器N变化会引发大量对象的重新分布miss 风暴。一致性哈希的做法是用哈希函数把每台服务器按名称/IP映射到环形哈希空间数据对象按同一哈希函数映射到环上从对象位置顺时针寻找第一个服务器即为归属新增服务器时只有环上逆时针方向紧邻的少量对象需要迁移其余对象不受影响。这正是 Amazon DynamoDB、Apache Cassandra、Akamai CDN 等系统选择一致性哈希的原因——在扩容与故障恢复时最小化数据搬迁详见 一致性哈希 中的真实应用梳理。分片落地方式与挑战分片速成课 还区分了三种落地方式应用层分片应用代码自行决定请求发往哪个分片中间件分片分片逻辑由应用与数据库之间的中间件承担数据库原生分片数据库系统原生提供分片能力。同时需正视挑战架构复杂度上升、分片键选择决定数据是否均匀、跨分片 Join 与事务困难常需分布式事务方案、重新分片Resharding昂贵且耗时。七个模式的组合从单点走向完整系统七个模式在真实系统中极少孤立存在而是层层咬合Ambassador Circuit Breaker大使容器是熔断、超时、限流等弹性逻辑的最佳落点业务代码保持干净CQRS Event Sourcing CDC写侧以事件日志为源通过 CDC 同步读侧投影出查询视图——三者形成一套完整的可追溯 高并发读写数据底座Pub/Sub Event SourcingKafka 既是事件存储又是消息代理天然把事件溯源与发布订阅融合如购物车事件驱动欺诈/计费/邮件服务Sharding 一致性哈希分片规模随流量弹性伸缩一致性哈希让扩缩容代价最小化Leader Election 心跳/仲裁选举结果依赖健康监测而仲裁规则又保障了选举的正确性。选型时建议自问三个问题失败时希望系统如何表现选弹性类模式、读写是否天然不对称考虑 CQRS/Event Sourcing、数据是否会超出单机边界考虑 Sharding。答案一旦明确上文七个模式就能各自归位、组合成网。延伸阅读想进一步深入每个模式可在本仓库继续研读弹性模式熔断、超时、重试、限流、舱壁、背压等 8 种故障防御手段全览数据管理模式Cache Aside、物化视图、CQRS、事件溯源、索引表、分片六种数据模式分布式系统节点故障检测六种心跳机制与仲裁详解如何将事件溯源融入系统纽约时报、CDC、微服务三大案例变更数据捕获实时数据的关键Debezium Kafka Connect 五步流程数据库分片速成课 与 四大分片算法分片键、算法与挑战一致性哈希从朴素哈希的痛点讲到哈希环一图看懂四种常用队列 与 代理 vs 反向代理理解消息代理与 Ambassador 的底层机制。赞分享后端文档教程【免费下载链接】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点击查看免费下载相关推荐Video2X基于机器学习的视频超分辨率与帧插值工具Video2X基于机器学习的视频超分辨率与帧插值工具 在数字视频处理领域低分辨率视频的增强和帧率提升一直是技术挑战。Video2X作为一个基于机器学习的开源音视频视频处理图像处理深度学习Gigatoken用户指南多线程并行处理、文件批量编码与内存优化技巧Gigatoken用户指南多线程并行处理、文件批量编码与内存优化技巧 Gigatoken是一款高性能的语言模型分词工具实现了GB/s级别的处理速度支持多线人工智能NLP系统设计终极指南如何利用CQRS模式彻底分离读写操作系统设计终极指南如何利用CQRS模式彻底分离读写操作 在现代系统设计中处理高并发读写场景是开发者面临的常见挑战。 system design resourc教程上一篇5步轻松备份QQ空间GetQzonehistory帮你永久保存青春记忆下一篇终极解决方案SD WebUI内存释放扩展彻底告别GPU显存泄露创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考