从内部工作原理到经典难题，从 CAP 定理到 Raft 算法，一次搞清楚分布式系统的核心思想与工程实践。
多台独立计算机通过网络协同，对外表现为单一整体，共同完成超出单机能力的任务。
所有组件在同一进程，简单易调试，但单点故障即全局瘫痪，伸缩性差。
多节点通过网络通信，每个节点独立运行，共同完成业务，可水平扩展。
增加节点数量扩展能力，理论上线性提升吞吐量，QPS 百万级成为可能。
部分节点故障不影响整体，系统继续运行并自动检测、隔离、恢复故障节点。
节点通信、服务发现、负载均衡、数据复制——完整工作流程拆解。
节点如何在集群中相互找到？
流量如何分配到各节点？
| 策略 | 原理 | 场景 |
|---|---|---|
| 轮询 | 依次分配 | 同质节点 |
| 加权轮询 | 按权重比例 | 节点性能不等 |
| 最小连接 | 选连接数最少 | 长连接 |
| 一致性哈希 | 哈希环映射 | 缓存亲和 |
| 随机 | 随机选节点 | 简单场景 |
Leader 每 150ms 发送心跳。Follower 超过 election timeout (300~500ms) 未收到心跳，则发起新选举。
分布式系统的经典挑战，每一个都需要精心的工程设计来应对。
网络故障导致集群分裂，各子集无法感知彼此状态。此时在继续服务与保证一致性之间必须二选一。
节点 A 写入 x=100，但节点 B 仍返回旧值 x=99，原因是异步复制存在延迟。最终一致性系统中"最终"有多快是关键。
客户端超时重试，但服务端已成功处理第一次请求：扣款两次、订单重复、库存超扣。
分布式系统无法依赖本地时钟判断事件先后。物理时钟可能相差数百毫秒，NTP 同步甚至可能造成时间倒退。
Service A 持有 R1 等待 R2，Service B 持有 R2 等待 R1，形成跨节点循环等待，单机死锁检测无法发现。
节点可能被攻击并发送错误消息。普通 Raft/Paxos 假设节点宕机但不作恶，无法应对拜占庭故障。
一致性（C）、可用性（A）、分区容错（P）——分布式系统永恒的权衡。
| 级别 | 定义 | 延迟 | 典型系统 |
|---|---|---|---|
| 强一致性 (Linearizable) | 写完立即所有节点可见，如同单机 | 高 | ZooKeeper, etcd, Spanner |
| 顺序一致性 | 全局操作有序，按程序顺序执行 | 中高 | 分布式锁服务 |
| 因果一致性 | 有因果关系的操作保序，无关可乱序 | 中 | MongoDB Causal, Cassandra LWT |
| 最终一致性 | 最终所有副本收敛到相同值 | 低 | DynamoDB, Cassandra, Redis |
| 读己写一致 | 自己写的值自己能立即读到 | 低-中 | MySQL 主从（读主库） |
多节点如何就某个值达成一致？共识算法是分布式系统的基石。
点击节点投票，观察 Quorum 达成（需 N/2+1 票）。
election timeout 内未收到心跳，转为 Candidate，Term++。
向所有节点发送投票请求，携带当前 Term 和日志信息。
超过半数节点投票（每 Term 每节点只投一票），成为新 Leader。
立即发送心跳，阻止其他 Candidate 发起选举。
Leader 追加 log entry，状态标记为 Uncommitted。
通过 AppendEntries RPC 并发将日志发送给所有 Follower。
超过半数 Follower 响应 ACK，Leader 提交（Committed），更新 commitIndex。
应用 committed log，通知 Follower commit，响应客户端。
选唯一递增提案号 n，向所有 Acceptor 广播 Prepare(n)。
若 n > minProposal，承诺不再接受更小提案，返回已接受的最大值。
收到多数 Promise 后，选最大 acceptedN 的值（或自选值），广播 Accept。
若 n ≥ minProposal 则接受，通知 Learner。多数接受即共识达成。
| 维度 | Raft | Multi-Paxos | ZAB (ZooKeeper) |
|---|---|---|---|
| 设计目标 | 易理解、易实现 | 理论证明完备 | 高吞吐主备复制 |
| Leader 选举 | 随机超时 + Term | Prepare 阶段竞争 | Fast Leader Election |
| 日志复制 | 强 Leader 驱动 | 可多 Proposer | Leader 广播 |
| 脑裂防护 | Term 编号 | 提案号 | Epoch 编号 |
| 实现复杂度 | 低（推荐） | 极高 | 中 |
| 代表系统 | etcd, TiKV, CockroachDB | Chubby, 部分存储 | ZooKeeper |
单机 ACID 无法跨越网络边界，分布式事务是最复杂的工程问题之一。
协调者（Coordinator）统一管理参与者（Participant）的提交与回滚。
PrepareYes/NoCommitRollback，全部回滚拆解为一系列本地事务，通过补偿操作（Compensating Transaction）实现回滚。
经业界验证的稳定性模式，构建高可用分布式系统的工程基石。
| 方案 | 原理 | 优点 | 缺点 | 场景 |
|---|---|---|---|---|
| 数据库行锁 | SELECT FOR UPDATE / 唯一索引 | 简单 | 性能差，易死锁 | 低并发 |
| Redis SETNX | 原子指令占锁+过期 | 性能高，简单 | 单点，锁超时误删 | 高并发 |
| Redis Redlock | 多数节点加锁 | 容忍单点故障 | 实现复杂，有争议 | 高可靠要求 |
| ZooKeeper | 有序临时节点+Watch | 强一致，自动释放 | 性能差，运维成本高 | 强一致 |
| etcd 租约 | Lease + Watch + Raft | 强一致，云原生 | 分区时可能阻塞 | K8s等 |