• 后端
• 文档
• 教程

分布式系统面对的核心挑战从未改变：节点会宕机、网络会延迟、数据会增长、流量会爆发。本指南以 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 本质上是一类"贴着应用部署的反向代理"：它拦截本服务对外部依赖的所有出站流量（也常承载入站流量），把本来散落在业务代码中的网络健壮性逻辑集中管理。

典型职责清单

收益与代价

• 收益：语言无关、部署无关，业务团队可以独立升级代理而不改动应用；所有服务获得一致的网络行为基线；
• 代价：每实例多一个容器意味着更多资源开销与运维复杂度；引入额外的网络跳数。

2. Circuit Breaker：给下游故障装一个"断路器"

核心思想

Circuit Breaker（熔断器）模式借鉴家庭电路中的空气开关：当下游服务连续失败达到阈值时，熔断器"跳闸"，后续请求不再真实打到下游，而是快速失败或走降级逻辑；经过一段冷却时间后，熔断器进入半开状态，放行少量探测请求验证下游是否恢复，成功则闭合、失败则再次跳闸。

为什么要熔断

弹性模式 一文列举了 8 种降低故障损伤的云设计模式：超时（Timeout）、重试（Retry）、熔断（Circuit breaker）、限流（Rate limiting）、削峰（Load shedding）、舱壁（Bulkhead）、背压（Back pressure）、让它崩溃（Let it crash），并强调这些模式通常组合使用。

熔断器的独特价值在于阻止"级联失败"：若一个服务对下游的调用无脑重试，下游已经过载时只会雪上加霜。熔断器通过快速失败让故障局部化，同时配合超时（防止线程长期阻塞）与重试（只在适当阶段重试）形成完整防线。

状态机与关键参数

实现熔断器通常需要：一个滑动窗口内的失败计数/失败率、状态切换的阈值配置、以及打开状态下对调用方的降级响应（缓存、默认值、错误提示）。

与其他弹性模式配合

• 熔断 + 超时：超时防止单个请求悬挂，熔断防止系统性过载；
• 熔断 + 重试：只对幂等操作重试，且重试必须穿过熔断状态机的约束；
• 熔断 + 舱壁（Bulkhead）：舱壁为不同依赖分配独立的线程池/连接池，一个依赖打满不影响其他依赖，与熔断互补。

3. CQRS：读写分离，让查询与命令各取所需

核心思想

CQRS（Command 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等事件，订单当前状态由这些事件推导，且历史永远可回溯。

三大典型落地场景

如何将事件溯源融入系统 一文给出了三个极具代表性的案例：

1. 《纽约时报》：把自 1851 年以来的文章、图片与署名全部存进事件存储，原始数据再反规范化（denormalize）成不同视图，喂给多个 ElasticSearch 节点支撑网站搜索——历史存档与多视图投影的完美示范；
2. CDC（变更数据捕获）：CDC 连接器从数据库表中拉取变更并转换为事件，推入 Kafka，其他 sink 从 Kafka 消费事件——事件溯源思想与流式管道的结合；
3. 微服务连接器：购物车服务产生"加购/移出购物车"等事件，Kafka 充当事件存储，欺诈服务、计费服务、邮件服务各自消费事件——因为事件是事实来源，每个服务可以自行确定自己的领域模型，服务间实现数据级解耦。

与 CDC 的关系

变更数据捕获：实时数据的关键 一文把 CDC 的流程拆为五步：数据变更 → 变更捕获（监控事务日志）→ 变更处理（转换成下游格式）→ 变更传播（发布到消息队列）→ 实时集成（sink 连接器消费并更新目标系统）。典型的 CDC 方案是 Debezium + Kafka Connect + Kafka：Debezium 为 MySQL、PostgreSQL、Oracle 等主流数据库提供连接器。CDC 让事件溯源思想得以"零侵入"地接入既有关系型数据库——用户只需关心业务写入，其余步骤全部透明。

收益与代价

• 收益：完整审计轨迹（每一次变更都留痕）；可随时重建任意历史状态；支持事件重放、回滚与调试；天然适配 CQRS 的投影模型；
• 代价：事件日志无限增长需要快照（Snapshot）压缩；事件模式演化（schema evolution）需要版本管理；最终一致性带来的查询延迟。

5. Leader Election：让分布式集群"选出一个话事人"

核心思想

很多分布式协调问题——谁是主节点、谁负责写入、谁调度任务——本质上都需要从一群等价节点中选出一个 Leader。Leader Election（领导者选举）提供一种机制，让集群在 Leader 故障后自动选出新 Leader，从而保证系统持续可用。

与心跳、仲裁的关联

分布式系统节点故障检测 一文梳理了六种心跳机制，其中与选举关系最密切的是带仲裁（Quorum）的心跳：在 Paxos、Raft 这类一致性协议中，心跳用于建立与维持仲裁——只有大多数（majority）节点在线，系统才能做出决策，这直接决定了 Leader 是否可以安全履职。其他心跳机制同样服务于选举健康度评估：

• 基于推送的心跳：节点周期性发信号，超时即判失败——实现简单，但网络拥塞可能造成误判；
• 基于拉取的心跳：中心监控定期拉取状态——流量更小，但故障发现延迟更高；
• 带健康检查的心跳：心跳携带 CPU、内存、应用指标——信息更丰富，但开销更大；
• 带时间戳/带确认的心跳：用于区分存活与网络延迟、验证双向链路可用。

典型选举流程

1. 所有节点启动后以随机超时竞争 Leader（如 Raft 中的选举超时）；
2. 赢得选举的节点持续通过心跳宣告"我是 Leader"；
3. Follower 若在超时时间内收不到 Leader 心跳，便发起新一轮选举；
4. 配合仲裁规则，只有获得多数节点支持才能当选，避免脑裂（split brain）下出现多个 Leader。

收益与代价

• 收益：单点故障自愈，系统高可用；写入路径清晰（只有 Leader 处理写）；
• 代价：选举协议实现复杂（Raft/Paxos 皆为经典难题）；Leader 切换期间存在短暂不可用窗口；仲裁要求集群规模为奇数以规避平票。

6. Publisher/Subscriber：发布订阅，让生产者与消费者彻底解耦

核心思想

Publisher/Subscriber（发布/订阅）是一种异步消息传递模式：发布者不直接调用具体消费者，而是把消息发布到主题（Topic）/代理（Broker）；订阅者按兴趣订阅主题，由代理负责扇出（fan-out）投递。发布者不知道订阅者是谁、有多少个，订阅者也无需关心消息从哪来。

与队列的对比

理解发布订阅前，先看仓库 一图看懂四种常用队列 的梳理：

传统点对点队列中一条消息只被一个消费者消费（竞争消费）；而 Pub/Sub 的核心差异是一条消息可被多个订阅者各消费一份——这是事件广播、数据扇出的基础。

在仓库案例中的位置

Pub/Sub 贯穿仓库多个真实案例：

• CDC 管道：Debezium 把数据库变更写入 Kafka（Topic），多个 sink（数据仓库、分析平台、Redis 缓存）作为订阅者各取所需（见 CDC 一文）；
• 事件溯源微服务：购物车服务发布事件到 Kafka，欺诈、计费、邮件服务分别订阅，各自维护领域模型（见 事件溯源融入系统）。

关键设计考量

• 投递语义：至少一次（at-least-once）、至多一次（at-most-once）、恰好一次（exactly-once）各有代价，需按业务容忍度选择；
• 顺序性：Kafka 等代理以分区（partition）为单位保证分区内有序，跨分区不保证全局有序；
• 背压与积压：消费者慢于生产者时，需通过批量消费、扩容分区等手段消化积压（结合弹性模式中的背压思想）。

收益与代价

• 收益：发布者与订阅者生命周期解耦；天然支持一对多广播与异步削峰；
• 代价：消息可能丢失或重复（需幂等消费）；链路延迟增加；消息中间件本身成为新的高可用依赖。

7. Sharding：把数据切开，摊到多台机器上

核心思想

Sharding（分片）也叫水平分区：把一张超大的表/数据集按分片键切分成多份，每份（shard）存放在不同数据库服务器上，所有分片合起来构成完整数据集。分片是分布式存储与数据库横向扩展的基石。

为什么需要分片

数据库分片速成课 一文总结了三大动机：

• 单机数据量太大：一台数据库服务器能容纳的数据有上限；
• 单机请求太多：一台服务器能承受的请求量有上限；
• 查询延迟升高：数据增长导致单表查询越来越慢。

核心概念：分片键与分片算法

分片键（Sharding Key）是决定数据分布到哪个分片的列；分片算法根据分片键计算归属。四大分片算法 一文梳理了四类主流算法：

此外，分片速成课 还提到了目录式分片（Directory-Based）：用一张查找表（目录）维护分片键到分片位置的映射。

一致性哈希详解

一致性哈希 一文对比了朴素哈希的痛点：serverIndex = hash(key) % N在集群规模固定时表现良好，但一旦新增或下线服务器，N变化会引发大量对象的重新分布（"miss 风暴"）。一致性哈希的做法是：

1. 用哈希函数把每台服务器（按名称/IP）映射到环形哈希空间；
2. 数据对象按同一哈希函数映射到环上；
3. 从对象位置顺时针寻找第一个服务器，即为归属；
4. 新增服务器时，只有环上逆时针方向紧邻的少量对象需要迁移，其余对象不受影响。

这正是 Amazon DynamoDB、Apache Cassandra、Akamai CDN 等系统选择一致性哈希的原因——在扩容与故障恢复时最小化数据搬迁（详见 一致性哈希 中的真实应用梳理）。

分片落地方式与挑战

分片速成课 还区分了三种落地方式：

• 应用层分片：应用代码自行决定请求发往哪个分片；
• 中间件分片：分片逻辑由应用与数据库之间的中间件承担；
• 数据库原生分片：数据库系统原生提供分片能力。

同时需正视挑战：架构复杂度上升、分片键选择决定数据是否均匀、跨分片 Join 与事务困难（常需分布式事务方案）、重新分片（Resharding）昂贵且耗时。

七个模式的组合：从单点走向完整系统

七个模式在真实系统中极少孤立存在，而是层层咬合：

• Ambassador + Circuit Breaker：大使容器是熔断、超时、限流等弹性逻辑的最佳落点，业务代码保持干净；
• CQRS + Event Sourcing + CDC：写侧以事件日志为源，通过 CDC 同步，读侧投影出查询视图——三者形成一套完整的"可追溯 + 高并发读写"数据底座；
• Pub/Sub + Event Sourcing：Kafka 既是事件存储又是消息代理，天然把事件溯源与发布订阅融合（如购物车事件驱动欺诈/计费/邮件服务）；
• Sharding + 一致性哈希：分片规模随流量弹性伸缩，一致性哈希让扩缩容代价最小化；
• Leader Election + 心跳/仲裁：选举结果依赖健康监测，而仲裁规则又保障了选举的正确性。

选型时建议自问三个问题：失败时希望系统如何表现（选弹性类模式）、读写是否天然不对称（考虑 CQRS/Event Sourcing）、数据是否会超出单机边界（考虑 Sharding）。答案一旦明确，上文七个模式就能各自归位、组合成网。

延伸阅读

想进一步深入每个模式，可在本仓库继续研读：

• 弹性模式：熔断、超时、重试、限流、舱壁、背压等 8 种故障防御手段全览；
• 数据管理模式：Cache Aside、物化视图、CQRS、事件溯源、索引表、分片六种数据模式；
• 分布式系统节点故障检测：六种心跳机制与仲裁详解；
• 如何将事件溯源融入系统：纽约时报、CDC、微服务三大案例；
• 变更数据捕获：实时数据的关键：Debezium + Kafka Connect 五步流程；
• 数据库分片速成课 与 四大分片算法：分片键、算法与挑战；
• 一致性哈希：从朴素哈希的痛点讲到哈希环；
• 一图看懂四种常用队列 与 代理 vs 反向代理：理解消息代理与 Ambassador 的底层机制。

• 后端
• 文档
• 教程