AI Infra Handbook

主题

3. 架构设计 ​

分布式系统的“架构”不是一幅静态图纸，而是一组在故障、延迟、容量之间做 trade-off 的组织原则。本章把这些原则抽象成几个常见模式：分层、Leader-Follower、复制拓扑、分片与故障域。

3.1 分层架构 ​

一个典型的分布式系统可以拆成四层：

层级职责AI Infra 例子
客户端发起任务、读写数据kubectl apply、训练脚本 torchrun
协调层发现、调度、一致性、锁Kubernetes apiserver/etcd、Ray GCS
计算层实际执行计算GPU worker、推理副本
存储层数据持久化与共享对象存储、并行文件系统、KV 元数据

分层的好处是：每层可以独立扩展、独立容错、独立选型。例如存储层可以用最终一致的对象存储，而协调层必须用强一致的 etcd。

3.2 Leader-Follower ​

**Leader-Follower（主从复制）**是最常见的复制模式：

  • 所有写请求发给 Leader；
  • Leader 把操作复制到 Follower；
  • 读请求可以走 Leader（强一致）或 Follower（可能读到旧数据）。

优点：简单、一致性强。 缺点：Leader 是单点写入瓶颈，故障时需要选举新 Leader。

工程优化：几乎所有生产系统（etcd、TiKV、CockroachDB）都在 Leader-Follower 之上叠加了租约读（lease read）——leader 只要按时收到多数派心跳，就能直接在本地服务只读请求，绕过一轮共识，把读延迟从两个 RTT 降到接近零。代价是读可能短暂过期，etcd 3.6/3.7 多次修复的正是这类过期读边界情况（见源码分析章）。

代表系统：MySQL 主从、Redis Sentinel、Kafka partition leader、Raft 集群。

3.3 Multi-Leader ​

**Multi-Leader（多主复制）**允许存在多个写入节点，常用于：

  • 多区域部署，降低写入延迟；
  • 离线设备同步；
  • 需要高可用的写入口。

代价是必须处理写冲突（conflict resolution），常用方法：

  • 最后写入者胜（LWW）；
  • 向量时钟 / 版本向量；
  • CRDT（无冲突复制数据类型）——2024 年后生产案例明显增多：Figma 的多人协同、Linear 的同步引擎、Bluesky 的 AT Protocol 都采用 CRDT 或其变体解决多端并发编辑。

代表系统：Couchbase、TIDB 部分场景、PostgreSQL logical replication。

3.4 Leaderless ​

**Leaderless（无主复制）**中，任何节点都可以接受写请求，客户端直接向多个副本读写，通过 quorum 判断最新值。

典型代表是 Dynamo：

  • 写：客户端并发写 N 个副本中的 W 个；
  • 读：客户端并发读 R 个副本，合并版本；
  • 如果 R + W > N，保证读到至少一个最新副本。

优点：高可用、无单点。 缺点：读修复（read repair）、冲突合并逻辑复杂。

3.5 State Machine Replication ​

**状态机复制（State Machine Replication, SMR）**是复制系统最核心的抽象：

  1. 所有副本从相同初始状态开始；
  2. 所有副本按相同顺序执行相同操作；
  3. 因此所有副本最终状态一致。
Client ──▶ Leader ──▶ Log: [op1, op2, op3] ──▶ Apply ──▶ State Machine
                           │
                           ▼
                        Followers apply same log

共识算法（Raft/Paxos）解决的是“如何让所有副本对日志顺序达成一致”。

代表系统：etcd、ZooKeeper、Raft-based KV 存储。

3.6 分片与一致性哈希 ​

3.6.1 分片（Sharding） ​

当数据量超过单节点容量时，需要把数据切分到多个节点。分片策略包括：

  • 范围分片：按 key 范围切分，适合范围查询；
  • 哈希分片：按 key 哈希切分，负载均衡但不支持范围查询；
  • 复合分片：先按时间/租户分片，再按 key 哈希。

3.6.2 一致性哈希 ​

一致性哈希把节点和数据都映射到一个环上：

  • 数据 key 顺时针找到第一个节点；
  • 增加或删除节点时，只影响相邻的一小段数据，不需要全量迁移。

代表系统：Cassandra、Dynamo、Memcached 客户端分片。

3.7 复制拓扑 ​

拓扑结构适用场景
链式复制Leader → Follower1 → Follower2高吞吐写入，读取延迟可接受
星型复制Leader 直接复制到所有 Follower最常见，读写均衡
全互联每个节点互相复制多主、P2P
树形复制分层聚合复制跨数据中心、日志聚合

AI Infra 例子：

  • 模型训练中的梯度聚合：环状 all-reduce（类似链式复制思想）；
  • 对象存储跨区域复制：主从或树形复制。

3.8 故障域与爆炸半径 ​

**故障域（Fault Domain）**指一起失效的一组资源。常见层级：

text
进程 → 节点 → 机架 → 机柜 → 可用区（AZ） → 区域（Region） → 云服务商

设计系统时，要让关键组件分散在不同故障域：

  • etcd 的 3/5/7 节点应跨机架、跨可用区部署；
  • 分布式训练的重要副本不要放在同一个机柜；
  • 对象存储的多副本应跨 AZ。

**爆炸半径（Blast Radius）**指一个故障影响的范围。好的设计会把爆炸半径控制在局部：

  • 按租户/命名空间隔离；
  • 分片独立故障；
  • 降级开关（circuit breaker）防止级联失败。

3.9 云原生新形态：Actor、Serverless 与 Durable Execution ​

2024-2026 年，分布式架构出现一组“把状态收敛到单写者单元”的新形态，绕开了共享状态 + 分布式锁的经典路线：

  • Actor / 虚拟对象：Cloudflare Durable Objects 把每个实体（房间、文档、会话）映射到一个全局唯一、单线程执行的 worker，状态由 SQLite 单写者持久化（SQLite-backed 存储于 2025 年 GA），Azure Orleans 的 Virtual Actor 思想与之同源。由于任意时刻只有一个执行者，冲突在结构上不可能发生，一致性问题是“不存在”而不是“被解决”。
  • Durable Execution：Temporal 等工作流引擎把长时间运行的业务逻辑本身变成持久化状态，进程崩溃后从上一次完成的活动恢复，把崩溃恢复从应用代码下沉到框架。
  • Serverless GPU：Modal、RunPod Serverless、Replicate 等平台把推理副本的弹性伸缩、排队、路由、冷启动全部下沉到平台层，用户面对的几乎是一个“单机的幻觉”。

对 AI Infra 的启示：推理会话、Agent 记忆、多轮对话上下文都可以建模为 Durable Object / Actor，从而避开多副本 KV Cache 共享一致性的泥潭——这是“故障域”与“爆炸半径”思想在应用架构层面的延续。

3.10 架构选型速查表 ​

需求推荐架构代表系统
强一致、小数据量Leader-Follower + 共识etcd、ZooKeeper
高可用、大数据量分片 + Leader-FollowerTiDB、CockroachDB
低延迟写、可容忍冲突Leaderless / Multi-LeaderDynamo、Cassandra
全局低延迟读副本 + 就近路由CDN、S3 跨区域复制
线性扩展计算分片 + 无状态 workerRay、FSDP
会话/Agent 状态单写者 ActorDurable Objects、Temporal Workflow

3.11 一句话总结 ​

分布式系统架构的本质，是把“状态、计算、协调”拆成可独立复制、分片和容错的单元，并通过 Leader-Follower、分片、quorum、共识等模式，在一致性、可用性和性能之间取得平衡。

Released under CC-BY-SA-4.0 License.

Copyright © 2026-present AI Infra Handbook Contributors