分布式系统知识体系概览

什么是分布式系统？

分布式系统（Distributed System） 是由多台独立的计算机通过网络协作，对外提供统一服务的系统。当单台服务器无法承受业务压力时（性能瓶颈、存储上限、单点故障），就需要将系统拆分到多台机器上——这就进入了分布式的领域。

用一个类比：单体应用像一个"全能员工"独自完成所有工作；分布式系统像一个"团队"——每个人负责不同的任务，通过沟通协作完成整体目标。团队高效，但也引入了新问题：沟通成本、任务协调、信息一致性。

---

分布式系统引入的核心挑战

挑战	说明	单机无此问题
网络不可靠	网络延迟、丢包、分区——节点间的通信随时可能失败	✅
数据一致性	多个节点的数据如何保持一致？	✅
时钟不统一	不同机器的时钟有偏差，无法用时间判断事件先后	✅
部分失败	系统的某些节点故障，其他节点仍需正常服务	✅

---

核心理论

CAP 定理——分布式的"不可能三角"

CAP 定理指出，分布式系统不可能同时满足以下三个特性，最多只能满足其中两个：

• C（Consistency，一致性）：所有节点在同一时间看到的数据一致
• A（Availability，可用性）：每个请求都能收到非错误的响应（但数据可能不是最新的）
• P（Partition Tolerance，分区容忍性）：网络分区发生时系统仍然能运行

为什么必须选 P？

在分布式系统中，网络分区是不可避免的现实（网线断裂、机房故障），所以 P 是必选项。实际的选择是 CP（一致性优先） 还是 AP（可用性优先）：

• CP 系统：ZooKeeper、Consul——网络分区时拒绝部分请求以保证数据一致
• AP 系统：Eureka、Nacos（默认）——网络分区时可能返回旧数据但保证可用

BASE 理论——CAP 的"柔性方案"

BASE 是 AP 思想的延伸——既然强一致性做不到，那就追求"最终一致性"：

• BA（Basically Available，基本可用）：允许响应时间变长或功能降级
• S（Soft State，软状态）：允许数据存在中间状态（暂时不一致）
• E（Eventually Consistent，最终一致性）：经过一段时间后，数据最终达到一致

---

核心知识点

分布式事务——跨服务的数据一致性

单机事务靠数据库保证，但当一个业务操作涉及多个服务（如下单 → 扣库存 → 扣余额），数据库事务就不够用了。

方案	原理	一致性	性能
2PC（两阶段提交）	协调者先 prepare 再 commit	强一致	低（同步阻塞）
TCC（Try-Confirm-Cancel）	业务层实现 try/confirm/cancel 三个方法	强一致	中等
Saga	每个服务执行本地事务 + 补偿操作	最终一致	高
本地消息表	将消息和业务数据写入同一个事务，异步投递	最终一致	高

Seata 是阿里开源的分布式事务框架，支持 AT（自动补偿）、TCC、Saga 三种模式。

分布式锁——多实例的"互斥访问"

实现方式	原理	优缺点
Redis	SET key value NX EX	性能高，但需要处理过期和锁续期
ZooKeeper	临时有序节点 + Watcher	可靠性高，但性能较 Redis 低
MySQL	SELECT ... FOR UPDATE 或唯一索引	简单，但性能差、不推荐高并发场景

分布式 ID 生成——全局唯一标识

分库分表后，数据库自增 ID 不再全局唯一。常见方案：

方案	原理	优缺点
UUID	128 位随机字符串	无需中心化，但无序、不适合做索引
雪花算法	时间戳 + 机器 ID + 序列号	有序递增、性能高，但依赖时钟同步
号段模式	从数据库批量获取 ID（如 Leaf）	中心化但性能好

一致性算法——分布式共识

多个节点如何就某个值达成共识？这是分布式系统最根本的问题。

• Raft：通过 Leader 选举 + 日志复制实现一致性，易于理解（Etcd、Consul 使用）
• ZAB：ZooKeeper 使用的原子广播协议，类似 Raft
• Paxos：分布式一致性的"鼻祖"算法，理论完美但实现复杂

---

学习建议

推荐学习路径

1. CAP + BASE → 理解分布式系统的基本约束
2. 分布式事务 → 2PC、TCC、Saga、本地消息表
3. 分布式锁 → Redis、ZooKeeper 实现与对比
4. 分布式 ID → 雪花算法、号段模式
5. 一致性算法 → Raft 原理（面试加分项）
6. 幂等性设计 → 分布式系统中的必备设计

相关链接

• Raft 可视化演示
• Seata 官方文档
• 分布式系统论文集