分布式系统是现代架构的重要组成部分，它通过多个节点协同工作以提供高可用性和扩展性。以下从系统模型、理论基础、事务处理、共识协议和分布式实践的角度，详细解析分布式系统的核心知识。
1. 概述：分布式系统的定义与优势
- 定义：分布式系统是跨多个节点运行的计算程序集合，通过协调实现整体功能。
- 优势：主要包括去中心化、低成本、弹性扩展、资源共享和高可靠性。
- 常见挑战：故障处理、网络延迟和安全性等。
2. 系统模型：故障与共识
2.1 故障模型
分布式系统可能面临各种故障，包括：
- 拜占庭故障：节点任意篡改信息，是最复杂的故障模型。
- 崩溃故障：节点停止响应，可以检测和处理。
- 故障应对：不同的故障模型要求不同的检测和处理手段。
2.2 拜占庭将军问题
拜占庭将军问题描述了在存在叛徒的情况下如何达成共识，证明了在一定数量的叛徒存在下无法保证一致性。Raft 和 Paxos 协议是典型的共识算法，旨在解决类似的问题。
3. 理论基础：CAP 和 ACID/BASE
3.1 CAP 理论
CAP 理论说明了分布式系统无法同时保证一致性 (Consistency)、可用性 (Availability) 和分区容错性 (Partition Tolerance)。
- CA 系统：传统数据库注重一致性和可用性。
- AP 系统：如 NoSQL，放弃一致性来实现高可用。
- CP 系统：如分布式数据库，优先保证数据一致性。
3.2 ACID 与 BASE
- ACID (原子性、一致性、隔离性、持久性) 保证事务的可靠执行。
- BASE (基本可用、软状态、最终一致性) 强调系统在大规模环境下的灵活性，特别适用于互联网场景。
4. 分布式事务：协调一致性
4.1 二阶段与三阶段提交
- 两阶段提交 (2PC)：通过 Prepare 和 Commit 两个阶段确保各节点的一致性，但存在性能瓶颈。
- 三阶段提交 (3PC)：在两阶段基础上增加 CanCommit，降低网络故障导致的停滞问题。
- MVCC (多版本并发控制)：通过版本管理来提高并发性能，避免读写冲突。
5. 共识协议：保证数据一致性
5.1 Raft 协议
- 角色划分：包含 Leader、Follower 和 Candidate 三种角色，通过选举机制确保系统的领导者。
- 日志复制：Leader 将请求日志同步给 Follower，保证数据的一致性。
- Stale 读问题：Leader 失效后，旧 Leader 响应读请求可能导致读到过时数据，需要通过读选举机制解决。
5.2 Paxos 协议
- 区别：Paxos 更灵活，可以并发修改日志，但恢复复杂。Raft 则提供连续写日志的方式，易于实现。
5.3 Quorum NWR 模型
- 三要素：N 为副本数，W 为写入的副本数，R 为读取的副本数。要保证强一致性，必须满足 W + R > N。
6. 分布式实践：常见应用
- MapReduce：适用于大规模数据处理，解决任务的并行化与容错问题。
- 分布式键值存储 (KV)：例如 Redis 和 Cassandra，保证数据的高可用与一致性。
7. 课后问题解答
- 为什么两将军问题无法解决？
- 因为通信信使可能被俘虏，双方永远无法确认对方已收到消息。
- TCP 为什么采用三次握手？
- 为了确保双方都能确认对方具备收发能力，避免两次握手导致的半开连接问题。
- CAP 理论中的矛盾
- 在网络分区情况下，需要在数据一致性和服务可用性之间做出取舍。
- RAFT 中如何处理冲突日志？
- 新 Leader 将覆盖 Followers 上不一致的日志，确保系统达成一致。
