第7阶段：分布式系统基石

目标

掌握分布式系统的核心理论（CAP、BASE）、一致性模型、分布式事务、共识算法、数据分片与负载均衡等，能够分析分布式架构的权衡与设计。

模块概览

模块 核心内容 与现实系统的关联
7.1 CAP 定理 一致性、可用性、分区容错性三者最多取其二 解释为什么 NoSQL 系统有不同的取舍（如 CP vs AP）
7.2 BASE 理论 基本可用、软状态、最终一致性 微服务与大规模系统的设计哲学
7.3 一致性模型 强一致性、弱一致性、最终一致性、顺序一致性等 数据库复制、分布式缓存的行为
7.4 分布式事务 2PC、3PC、TCC、Saga、本地消息表、事务消息 跨数据库或跨服务的原子操作
7.5 共识算法 Paxos、Raft、Zab 分布式选主、日志复制（etcd, ZooKeeper, Consul）
7.6 数据分片与路由 一致性哈希、范围分片、哈希分片、虚拟节点 分库分表、Redis Cluster、Cassandra
7.7 负载均衡与故障转移 服务发现、健康检查、熔断、重试、超时控制 Nginx、Consul、Netflix Hystrix

各模块详细学习要点

7.1 CAP 定理

  • 定义：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）中的两个。
  • C：所有节点在同一时间看到相同的数据。
  • A：每个请求都能收到非错误的响应（但不保证是最新数据）。
  • P：网络分区（节点间通信中断）发生时，系统仍能继续运行。
  • 现实意义：网络分区必然发生，因此实际需要在 C 和 A 之间权衡。
  • CP 系统：牺牲可用性，保证数据一致（如 ZooKeeper、HBase）。
  • AP 系统：牺牲强一致性，保证可用（如 Cassandra、CouchDB）。
  • CA 系统：实际上不存在（因为无法容忍分区），单机数据库即 CA（但无分布式能力）。
  • 误区：CAP 不是“三选二”，而是分区发生时，C 和 A 只能二选一；无分区时系统可同时达成 C+A。

7.2 BASE 理论

  • 背景：对 CAP 中 AP 系统的补充，强调最终一致性而非强一致性。
  • 含义：
  • Basically Available：基本可用（部分节点故障不影响整体可用性，但可能响应变慢或功能降级）。
  • Soft State：软状态（数据状态可以有一段时间不同步，允许中间状态）。
  • Eventually Consistent：最终一致性（经过一段时间后，所有副本数据最终达到一致）。
  • 与 ACID 对比：ACID 是强一致性、强隔离性；BASE 是弱一致性、高可用，适合大规模互联网应用。

7.3 一致性模型（从强到弱）

模型 特点 典型系统
线性一致性 最强，所有操作按真实时间顺序原子执行 单主数据库、etcd
顺序一致性 程序顺序与执行顺序一致，不要求全局时间 分布式共享内存
因果一致性 有因果关系的操作顺序一致，无关操作可并发 某些版本向量时钟系统
最终一致性 不保证立即一致，但保证最终收敛 DNS、异步复制数据库
弱一致性 没有收敛保证 某些缓存系统

7.4 分布式事务

  • 2PC（两阶段提交）：
  • 准备阶段：协调者询问所有参与者是否可以提交。
  • 提交/回滚阶段：根据所有参与者的答复，决定全局提交或回滚。
  • 缺点：阻塞、单点故障（协调者崩溃）、性能差。
  • 3PC：增加超时机制，缓解阻塞问题，但仍复杂，实际使用较少。
  • TCC（Try-Confirm-Cancel）：
  • Try：预留资源（如冻结库存）。
  • Confirm：真正执行业务（扣减库存）。
  • Cancel：释放预留资源。
  • 适用于业务高并发场景，需要业务方实现补偿逻辑。
  • Saga：
  • 将长事务拆分为多个本地事务，每个事务有对应的补偿事务。
  • 两种协调方式：事件驱动（每个服务监听事件并发布事件）或指令式（协调器依次调用）。
  • 保证最终一致性。
  • 本地消息表 + 消息队列：事务性发送消息（如 RocketMQ 事务消息），确保消息发送与本地操作原子性。

7.5 共识算法

  • Paxos：
  • 第一个被证明正确的共识算法，但复杂难实现。
  • 角色：提议者（Proposer）、接受者（Acceptor）、学习者（Learner）。
  • 两阶段：Prepare/Promise → Accept/Accepted。
  • Raft（更易理解）：
  • 三个子问题：领导者选举、日志复制、安全性。
  • 状态转换：Follower → Candidate → Leader。
  • 选举基于超时和任期号。
  • 日志条目必须通过多数派提交，保证一致性。
  • Zab（ZooKeeper Atomic Broadcast）：ZooKeeper 使用，类似 Raft，但强调顺序广播。
  • 应用场景：分布式锁、选主、配置管理、元数据存储（etcd, ZooKeeper, Consul）。

7.6 数据分片与路由

  • 为什么需要分片：单机数据量或负载超过上限。
  • 分片策略：
  • 范围分片：按主键范围（如用户 ID 1-1000 到节点1，1001-2000 到节点2）。优点：范围查询高效；缺点：易产生热点。
  • 哈希分片：对分片键计算哈希值，取模映射到节点。优点：分布均匀；缺点：节点增减时大量数据迁移。
  • 一致性哈希：哈希环 + 虚拟节点，节点增减时只有少量数据重映射。广泛用于缓存和分布式存储。
  • 分片路由：客户端路由（如 Redis Cluster Smart Client）、代理中间件（如 ShardingSphere）、分布式查询引擎。

7.7 负载均衡与故障转移

  • 服务发现：
  • 客户端侧发现（如 Eureka、Consul）：客户端从注册中心获取服务地址列表。
  • 服务端侧发现（如 Kubernetes Service）：通过负载均衡器（kube-proxy）转发。
  • 健康检查：主动探测（心跳）、被动探测（TCP 连接失败）。
  • 负载均衡算法：轮询、加权轮询、最小连接数、一致性哈希（保持会话粘性）。
  • 容错模式：
  • 熔断：故障比例超过阈值后快速失败，避免级联故障（Circuit Breaker）。
  • 重试：有限次数重试，配合退避策略。
  • 超时：设置合理超时，避免长时间阻塞。
  • 降级：返回缓存或默认值。
  • 限流：令牌桶、漏桶、计数器。

关键公式与原则

  • Quorum 机制：读写的节点数必须满足多数派，以保证一致性的基本策略（N = 副本数，R = 读需要的最少节点，W = 写需要的最少节点，需满足 R + W > N）。
  • MVCC（多版本并发控制）：通过保存数据快照实现无锁读取，广泛用于数据库（PostgreSQL、MySQL InnoDB）和分布式系统。
  • Hints for 学习：先理解 Raft（最实用），再了解 Paxos 理论基础；理解一致性哈希的原理与实际应用（如 Redis Cluster、Cassandra）。

第7阶段与其他阶段的关系

  • 衔接第6阶段（安全认证）：分布式系统下的 SSO、会话存储需要分布式缓存（如 Redis）和共识算法（如 leader 选举）。
  • 衔接第4阶段（软件架构）：微服务架构依赖服务发现、分布式事务、熔断等模式，理论支撑实践。
  • 支撑第8阶段（可观测性）：分布式追踪需要理解跨服务的因果关系和时间偏移。