分布式系统可视化
多机系统会遇到三个不同问题：每个键放在哪里？多个资源如何一起提交事务？多个副本如何在故障中保留一致的已提交日志？一致性哈希、两阶段提交和 Raft 分别回答它们。画面都有节点和消息，不代表保证可以互换。
缓存环需要在容量变化时尽量少迁移键；转账需要 A、B 与审计日志同时改变或全不改变；复制控制平面需要在消息延迟和网络分区中保留一份已提交历史。先明确目标，再选机制。
课程比较
| 课程 | 主要问题 | 决定规则 | 失败边界 |
|---|---|---|---|
| 一致性哈希 | 成员变化时哪个物理节点拥有键 | 从固定键位置顺时针遇到的第一个活动 token | 一次单 token 变化只影响邻接区间；均衡可能改善，不保证完美 |
| 两阶段提交 | A、B 和日志何时可一起改变 | 所有参与者 YES，再收到同一决定 | 一票 NO 使所有人中止，协调者崩溃可能让准备锁一直保留 |
| Raft 共识 | 日志项何时成为已提交历史 | 多数选出领导者，多数存储其当前任期条目 | 少数可以存储，不能提交 |
Raft 的五取三不能替代三资源事务的原子提交。若把 2PC 的全票要求套在五副本日志上，两个延迟副本就会阻塞它。一致性哈希只决定归属，不提供数据复制或冲突写入裁决。
建议学习顺序
先学一致性哈希的节点加入场景。跟踪 K11 跨过 token 零点，再看 N4@220 接管 (140, 220]。K5、K6、K7 换归属，另外九个键不动。节点退出时，其区间交给顺时针后继。虚拟节点场景对比同一批键的负载：3/2/7 -> 4/5/3。
再学两阶段提交的全票提交场景。在只有两票 YES、协调者作出 COMMIT，以及 P1 仍 PREPARED、A 仍为 100 的等待窗口分别暂停。再看一票 NO 如何让已投 YES 的参与者回滚，协调者崩溃如何留下准备锁。
最后学 Raft 共识的选举与提交。三票产生领导者，当前任期条目存到三个副本后才可提交。少数分区中的两个服务器可以存下 set y=7，却停在 2 / 5；另外三个服务器选出更高任期领导者，在相同索引提交不同条目。
这个顺序依次学习放置、原子协调和复制一致性。键的拥有者、事务参与者、准备值、已提交日志项、哈希 token 和法定票数各有不同含义。
观察重点
- 成员改变时，键的位置不动，变化的是顺时针后继。
- 虚拟节点是同一物理机器的另一个 token 位置，不是新机器。
- 2PC 的紫色提议值已经锁定，但尚未应用。两票 YES 不满足
need ALL YES。 - Raft 的两份副本不满足
majority = 3，存储和提交是不同步骤。 - 协调者崩溃可阻塞已准备的 2PC 参与者；Raft 分区中，缺少多数的一侧无法提交。
- 三种机制不提供彼此的保证。实际系统可以组合使用，例如哈希环负责放置，分片内部用 Raft 复制。
选择课程，跟踪真正决定结果的证据：顺时针后继、全票同意或多数派。