六、分布式系统理论基础

6.1 分布式系统概述

分布式系统是指由多个通过网络通信的计算机节点组成的系统，这些节点相互协作来完成共同的目标。对用户而言，整个系统就像一个单一的计算资源。

核心特征

• 透明性：用户无需知道系统的分布式特性
• 可扩展性：可以通过增加节点来提升系统能力
• 容错性：部分节点故障不影响整体服务
• 并发性：多个节点可以同时处理请求

---

6.2 CAP 定理

CAP 定理（Brewer's Theorem）指出，一个分布式系统最多只能同时满足以下三个特性中的两个：

1. Consistency（一致性）

所有节点在同一时间看到的数据都是相同的。

写操作成功后，所有读操作都必须返回最新的值

2. Availability（可用性）

系统提供的服务一直处于可用状态，每次请求都能在合理时间内获得响应。

每个请求都能得到响应，不保证是最新数据

3. Partition Tolerance（分区容错性）

当网络分区发生时（节点间通信失败），系统仍能继续运行。

网络故障导致节点分裂，系统仍能工作

CAP 三角权衡

        C
       / \
      /   \
     /     \
    A ----- P

组合	说明	典型场景
CP	保证一致性和分区容错性，牺牲可用性	分布式数据库（HBase、MongoDB）
AP	保证可用性和分区容错性，牺牲一致性	缓存系统（Redis Cluster）、DNS
CA	保证一致性和可用性，无法容忍分区	单机数据库（理论上，实际不存在）

实际系统的选择

现代分布式系统通常采用最终一致性模型，在 CAP 之间做灵活权衡：

• ZooKeeper：CP 系统，Leader 选举期间不可用
• Eureka：AP 系统，节点对等，始终可用
• Nacos：支持 CP/AP 切换
• Redis Cluster：AP 系统，支持最终一致性
• MongoDB：CP 系统（4.0 后支持更多一致性级别）

---

6.3 BASE 理论

BASE 理论是对 CAP 理论的延伸，强调即使无法做到强一致性（Strong Consistency），也可以采用适当的方式实现最终一致性（Eventual Consistency）。

BASE 三要素

1. Basically Available（基本可用）

系统出现不可预知的故障时，允许损失部分可用性来满足核心功能。

实现方式：

• 服务降级（返回兜底数据）
• 服务熔断（快速失败）
• 限流（拒绝部分请求）
• 异步处理（削峰填谷）

// 服务降级示例
@Service
public class OrderFallbackService implements OrderService {
    @Override
    public Order createOrder(OrderRequest request) {
        // 返回兜底数据，保证基本功能
        return Order.fallbackOrder(request);
    }
}

2. Soft State（软状态）

允许系统存在中间状态，且该中间状态不会影响系统整体可用性。

传统数据库：事务提交后，数据立即对所有客户端可见
软状态系统：数据可以在不同节点间异步复制，存在短暂不一致窗口

3. Eventual Consistency（最终一致性）

系统经过一段时间后，所有数据副本最终能达到一致状态。

最终一致性的变种：

类型	说明	场景
因果一致性	有因果关系的操作保证顺序	评论回复
读己之所写	用户总能读到自己之前的写入	用户配置
会话一致性	同一会话内保证读己之所写	购物车
单调读一致性	不会读到更旧的数据	消息流
单调写一致性	写操作按顺序执行	计数器

---

6.4 一致性协议

6.4.1 2PC（两阶段提交）

两阶段提交（Two-Phase Commit，2PC）是分布式事务的经典协议。

执行流程

阶段一：准备阶段（Voting Phase）
┌─────────────┐
│  Coordinator│
│  (协调者)    │
└──────┬──────┘
       │ 1. 发送 Prepare 请求
       ▼
┌─────────────────────────────────┐
│  Participant  │  Participant    │
│  (参与者 A)    │  (参与者 B)      │
└─────────────────────────────────┘
       │ 2. 执行事务，记录日志
       │ 3. 返回 Yes/No

阶段二：提交/回滚阶段（Commit Phase）
┌─────────────┐
│  Coordinator│
└──────┬──────┘
       │ 4. 根据投票结果决定 Commit/Rollback
       ▼
┌─────────────────────────────────┐
│  Participant  │  Participant    │
│  (参与者 A)    │  (参与者 B)      │
└─────────────────────────────────┘
       │ 5. 执行并提交/回滚
       │ 6. 返回 ACK

2PC 的缺点

1. 同步阻塞：所有参与者锁定资源等待协调者决策
2. 单点故障：协调者宕机导致整个事务挂起
3. 脑裂问题：网络分区可能导致数据不一致
4. 性能瓶颈：两阶段同步，延迟较高

6.4.2 3PC（三阶段提交）

三阶段提交（Three-Phase Commit，3PC）在 2PC 基础上增加了预提交阶段。

执行流程

阶段一：CanCommit（询问阶段）
┌─────────────┐      ┌─────────────┐
│ Coordinator│ ───► │ Participant │
│            │ ◄─── │             │
└─────────────┘      └─────────────┘
     询问是否可以提交          返回 Yes/No

阶段二：PreCommit（预提交阶段）
┌─────────────┐      ┌─────────────┐
│ Coordinator│ ───► │ Participant │
│            │ ◄─── │             │
└─────────────┘      └─────────────┘
     发送预提交请求        执行并返回 ACK

阶段三：DoCommit（提交阶段）
┌─────────────┐      ┌─────────────┐
│ Coordinator│ ───► │ Participant │
│            │ ◄─── │             │
└─────────────┘      └─────────────┘
     发送正式提交请求        提交并返回 ACK

3PC 的改进

• 降低阻塞：引入超时机制，超时自动回滚
• 减少单点影响：参与者在超时情况下可以自主决策

3PC 的问题

• 在网络分区场景下仍可能导致数据不一致
• 实现复杂度高，实际应用较少

6.4.3 Paxos 算法

Paxos 是一种基于消息传递的分布式一致性算法，由 Leslie Lamport 提出。

核心角色

角色	职责
Proposer（提议者）	提出提案（Proposal）
Acceptor（接受者）	对提案进行投票
Learner（学习者）	学习被批准的提案

两阶段协议

阶段一：Prepare 阶段
Proposer                Acceptor
   │                       │
   │─── Prepare(N) ───────►│
   │                       │ 若 N > maxProposalId
   │◄─── Promise(N) ───────│ 则返回 Promise
   │                       │

阶段二：Accept 阶段
Proposer                Acceptor
   │                       │
   │── Accept(N, V) ──────►│
   │                       │ 若未拒绝
   │◄── Accepted(N) ───────│ 则接受并广播
   │                       │

Paxos 的特点

• 强一致性：保证只有一个提案被批准
• 活锁问题：多个 Proposer 可能导致无法进展
• 实际变体：Multi-Paxos、Fast Paxos

6.4.4 Raft 算法

Raft 是一种易于理解的分布式一致性算法，用于管理复制状态机。

核心概念

节点状态：

• Leader：处理所有客户端请求，复制日志给 Follower
• Follower：接收 Leader 的心跳和日志复制
• Candidate：Leader 选举时的临时状态

节点状态转换

                    ┌─────────────┐
                    │   Follower  │
                    └──────┬──────┘
                           │ 选举超时
                           ▼
                    ┌─────────────┐
         选举失败   │  Candidate  │
        ◄──────────┤             │
                    │             │─── 获得多数票 ───► ┌─────────────┐
                    └─────────────┘                    │    Leader   │
                           │                           └─────────────┘
                           │ 发现更高任期的 Leader
                           ▼
                    ┌─────────────┐
                    │   Follower  │
                    └─────────────┘

Raft 的工作流程

1. Leader 选举

   • Follower 在选举超时后成为 Candidate
   • Candidate 请求其他节点投票
   • 获得多数票的成为 Leader

2. 日志复制

   • Leader 接收客户端请求
   • 将日志复制给 Follower
   • 多数节点确认后提交

3. 安全性保证

   • 只有包含最新日志的节点才能成为 Leader
   • 日志只能由 Leader 追加

Raft vs Paxos

对比项	Paxos	Raft
理解难度	高	低
角色	单一	Leader/Follower/Candidate
日志复制	灵活	强制从 Leader 到 Follower
应用	理论基础	etcd、Consul、TiDB

---

6.5 实践建议

技术选型考虑

1. 一致性要求

   • 强一致：金融交易、库存扣减 → 选 CP 系统
   • 最终一致：社交 feed、缓存 → 选 AP 系统

2. 可用性要求

   • 99.9% → 允许短暂不一致
   • 99.99%+ → 需要多活架构

3. 扩展性要求

   • 读多写少 → 读写分离、缓存
   • 写多读少 → 分库分表、队列削峰

常见问题及解决方案

问题	解决方案
分布式事务	TCC、Saga、本地消息表
分布式锁	Redis、ZooKeeper、数据库
数据一致性	对账系统、补偿机制
服务雪崩	熔断、降级、限流

---

下一章：分布式组件 →