系统架构教程第7章：分布式系统基础
章节头部 第7章
🌐 分布式系统基础
深入理解分布式系统的核心理论、一致性模型和关键技术
学习目标
学习目标
- 理解CAP定理的核心内容和实际应用
- 掌握BASE理论与ACID的区别和联系
- 学习分布式一致性的各种模型和算法
- 了解分布式事务的实现方式和挑战
- 掌握分布式锁的原理和实现方案
CAP定理
CAP定理
CAP定理是分布式系统设计的基础理论，由Eric Brewer在2000年提出。它指出在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三个特性最多只能同时满足两个。
CAP定理核心内容
**一致性（Consistency）：**所有节点在同一时间看到的数据是一致的
**可用性（Availability）：**系统在任何时候都能响应用户请求
**分区容错性（Partition tolerance）：**系统能够容忍网络分区故障
CAP的三种组合
CA系统
保证一致性和可用性，但不能容忍分区。
**典型例子：**传统关系型数据库（单机）
**适用场景：**对一致性要求极高的单机系统
CP系统
保证一致性和分区容错性，但可能牺牲可用性。
**典型例子：**MongoDB、Redis Cluster
**适用场景：**对数据一致性要求高的分布式系统
AP系统
保证可用性和分区容错性，但可能出现数据不一致。
**典型例子：**Cassandra、DynamoDB
**适用场景：**对可用性要求高的大规模分布式系统
实际应用考虑
在实际系统设计中，分区容错性通常是必须的，因此主要是在一致性和可用性之间做权衡。现代分布式系统往往采用最终一致性来平衡这两者。
BASE理论
BASE理论
BASE理论是对CAP定理的延伸，提供了一种在分布式系统中实现高可用性的方法。BASE代表基本可用（Basically Available）、软状态（Soft state）和最终一致性（Eventually consistent）。
BASE vs ACID
ACID特性
- 原子性（Atomicity）：事务要么全部成功，要么全部失败
- 一致性（Consistency）：事务执行前后数据保持一致
- 隔离性（Isolation）：并发事务之间相互隔离
- 持久性（Durability）：事务提交后数据永久保存
BASE特性
- 基本可用：系统在出现故障时仍能提供基本服务
- 软状态：允许系统存在中间状态
- 最终一致性：系统最终会达到一致状态
设计权衡
BASE理论牺牲了强一致性来获得更好的可用性和分区容错性。这种权衡适合大多数互联网应用，但不适合对一致性要求极高的金融系统。
分布式一致性
分布式一致性
分布式一致性是分布式系统中的核心问题，涉及如何在多个节点之间保持数据的一致性。根据一致性的强弱程度，可以分为强一致性、弱一致性和最终一致性。
一致性模型
强一致性
所有节点在任何时刻都能看到相同的数据。
**优点：**数据一致性保证强
**缺点：**性能和可用性较低
**应用：**金融交易系统
最终一致性
系统在一段时间后会达到一致状态。
**优点：**高可用性和性能
**缺点：**短期内可能不一致
**应用：**社交网络、内容分发
弱一致性
系统不保证何时达到一致性。
**优点：**最高的性能和可用性
**缺点：**一致性保证最弱
**应用：**实时游戏、视频直播
一致性算法
主要算法
Paxos算法：经典的分布式一致性算法，理论完备但实现复杂Raft算法：相对简单的一致性算法，易于理解和实现PBFT算法：拜占庭容错算法，能够处理恶意节点Gossip协议：最终一致性协议，适合大规模分布式系统
分布式事务
分布式事务
分布式事务是指跨越多个数据库或服务的事务操作。由于网络延迟、节点故障等因素，分布式事务的实现比单机事务复杂得多。
两阶段提交（2PC）
准备阶段
协调者向所有参与者发送准备请求，参与者执行事务操作但不提交，并返回准备结果。
提交阶段
如果所有参与者都准备成功，协调者发送提交请求；否则发送回滚请求。
2PC的问题
阻塞问题：协调者故障时参与者会一直等待单点故障：协调者是系统的单点故障数据不一致：网络分区可能导致数据不一致
三阶段提交（3PC）
3PC在2PC的基础上增加了超时机制和CanCommit阶段，减少了阻塞问题，但仍然无法完全解决数据一致性问题。
补偿事务（TCC）
TCC模式
Try：尝试执行业务操作，预留资源Confirm：确认执行，提交资源Cancel：取消执行，释放资源
分布式锁
分布式锁
分布式锁是分布式系统中用于控制对共享资源访问的机制。它确保在分布式环境中，同一时间只有一个进程能够访问特定的资源。
实现方案
数据库锁
利用数据库的唯一约束实现分布式锁。
**优点：**实现简单，强一致性
**缺点：**性能较低，依赖数据库
Redis锁
使用Redis的SETNX命令实现分布式锁。
**优点：**性能高，支持过期时间
**缺点：**可能存在锁失效问题
ZooKeeper锁
利用ZooKeeper的临时顺序节点实现分布式锁。
**优点：**可靠性高，支持阻塞等待
**缺点：**性能相对较低
Redis分布式锁实现
关键要点
原子性：使用Lua脚本保证操作的原子性过期时间：设置锁的过期时间防止死锁唯一标识：使用UUID等唯一标识防止误删续期机制：对于长时间任务需要锁续期
注意事项
避免死锁：合理设置锁的过期时间防止误删：释放锁时验证锁的所有者处理异常：确保在异常情况下能够释放锁性能考虑：选择合适的锁实现方案
章节导航 上一章：微服务架构 返回目录 下一章：负载均衡