分布式系统基础

分布式系统基础

本文介绍分布式系统的核心概念,包括 CAP 定理、服务发现、心跳机制以及 Actor 模型。


1. CAP 定理

1.1 三个保证

分布式系统中,不可能同时满足以下三个保证:

graph TB subgraph cap["CAP 定理"] C["Consistency
一致性"] A["Availability
可用性"] P["Partition Tolerance
分区容错性"] end C --- A A --- P P --- C
保证说明
Consistency所有节点在同一时间看到相同的数据
Availability每个请求都能收到响应(不保证是最新数据)
Partition Tolerance网络分区时系统仍能正常运行

1.2 系统分类

graph LR subgraph systems["系统分类"] CA["CA 系统
单节点数据库"] CP["CP 系统
etcd, ZooKeeper"] AP["AP 系统
Cassandra, DynamoDB"] end

1.3 Dynamo 的选择

平面系统类型原因
控制平面etcdCP服务注册需要强一致性
事件平面NATSAP事件传递优先可用性
数据平面NIXL-点对点传输,不涉及分布式一致性

2. 服务发现模式

2.1 客户端发现模式

客户端负责查询服务注册中心并选择实例:

sequenceDiagram participant Client as 客户端 participant Registry as 服务注册中心 participant S1 as 服务实例 1 participant S2 as 服务实例 2 S1->>Registry: 注册 S2->>Registry: 注册 Client->>Registry: 查询服务列表 Registry-->>Client: [S1, S2] Note over Client: 客户端选择实例
负载均衡 Client->>S1: 直接请求 S1-->>Client: 响应

优点

  • 客户端掌握完整的服务列表
  • 可以实现复杂的负载均衡策略

缺点

  • 客户端逻辑复杂
  • 需要为每种语言实现发现逻辑

2.2 服务端发现模式

由负载均衡器代理服务发现:

sequenceDiagram participant Client as 客户端 participant LB as 负载均衡器 participant Registry as 服务注册中心 participant S1 as 服务实例 1 S1->>Registry: 注册 Client->>LB: 请求 LB->>Registry: 查询 Registry-->>LB: [S1, S2] LB->>S1: 转发请求 S1-->>LB: 响应 LB-->>Client: 响应

优点

  • 客户端逻辑简单
  • 统一的服务发现接口

缺点

  • 增加网络延迟
  • 负载均衡器成为单点

2.3 Dynamo 的选择

Dynamo 使用客户端发现模式

  • 通过 etcd 存储服务注册信息
  • 客户端直接查询并选择服务实例
  • 支持复杂的路由策略(如 KV-Aware 路由)

3. 心跳与租约机制

3.1 为什么需要心跳

服务实例需要证明自己仍然存活:

  • 检测服务崩溃
  • 检测网络分区
  • 及时清理下线服务

3.2 Lease 租约机制

etcd 使用 Lease 机制管理服务健康:

sequenceDiagram participant Service as 服务实例 participant etcd as etcd Service->>etcd: 创建 Lease (TTL=10s) etcd-->>Service: Lease ID Service->>etcd: 注册服务 (绑定 Lease) loop 每 3 秒 Service->>etcd: Keep-Alive etcd-->>Service: OK end Note over Service: 服务崩溃 Note over etcd: 10 秒后 Lease 过期
自动删除注册信息

3.3 Lease 的优势

特性说明
自动清理Lease 过期后自动删除绑定的 Key
批量管理多个 Key 可以绑定同一个 Lease
原子性Lease 撤销时所有 Key 同时删除

4. Actor 模型

4.1 核心概念

Actor 模型是一种并发计算模型,每个 Actor 是独立的计算单元:

graph TB subgraph actor["Actor 模型"] A1["Actor 1
状态 + 行为"] A2["Actor 2
状态 + 行为"] A3["Actor 3
状态 + 行为"] M1["Mailbox 1"] M2["Mailbox 2"] M3["Mailbox 3"] end A1 --> |消息| M2 A2 --> |消息| M3 A3 --> |消息| M1 M1 --> A1 M2 --> A2 M3 --> A3

4.2 Actor 模型的特点

特点说明
封装状态Actor 的状态只能通过消息修改,无共享内存
异步消息Actor 之间通过消息通信,消息是异步的
位置透明Actor 可以在本地或远程,通信方式相同

4.3 Dynamo 中的应用

虽然 Dynamo 没有使用传统的 Actor 框架(如 Actix),但其设计借鉴了 Actor 模型的思想:

graph LR subgraph dynamo["Dynamo 中的 Actor 思想"] Comp["Component
类似 Actor"] EP["Endpoint
类似 Mailbox"] NATS["NATS
消息传递"] end Comp --> EP EP --> NATS NATS --> EP
Dynamo 概念Actor 对应
ComponentActor
EndpointMailbox
NATS消息传递系统

5. 一致性模型

5.1 强一致性 vs 最终一致性

graph TB subgraph strong["强一致性"] W1["写入节点 1"] --> R1["读取节点 2
立即看到最新值"] end subgraph eventual["最终一致性"] W2["写入节点 1"] --> SYNC["同步延迟"] SYNC --> R2["读取节点 2
稍后看到最新值"] end

5.2 Dynamo 的一致性选择

场景一致性模型实现方式
服务注册强一致性etcd Raft 共识
KV 索引最终一致性NATS 事件传播
指标聚合最终一致性定期同步

小结

本文介绍了分布式系统的核心概念:

  1. CAP 定理:一致性、可用性、分区容错性不可兼得
  2. 服务发现:客户端发现 vs 服务端发现
  3. 心跳机制:Lease 租约实现健康检查
  4. Actor 模型:消息驱动的并发模型

这些概念是理解 Dynamo 分布式运行时设计的基础。


下一篇

继续阅读 03-Runtime 双层设计,了解 Dynamo 的运行时架构。