第5章 分布式事务与一致性
第5章 分布式事务与一致性
本章跟着一条线走：多台机器不要只讨论"数据在哪儿"，还要能约定"多台机器怎么把一件事做成一遍"。这条线从"强、最终、因果三种约定"开始，讲透 2PC、3PC 这两种靠协调者硬保证的阻塞方案，再走到补偿与 Saga 这种"不锁死、靠修"的软路线，最后落到 MVCC 上——让"读不挡写、写不挡读"这件单机里便当的事，在分布式里也尽量体面。
本章路线图
一条主线
第 4 章帮我们把数据放好、能找到、送对门。现在难度再上一级：一个业务动作（比如下单）往往要改三张表、甚至跨两个节点，而业务要求它"要么全成、要么全不成"。这一章主线就是围绕"跨节点原子性做不做得到"展开的：两阶段提交（2PC）是其中最直接也最容易理解的一个答案——一个协调者拉起所有参与者投票，全票通过才提交；三阶段提交（3PC）试图用"预提交"缓冲缓解 2PC 的阻塞；而怕锁死时，补偿与 Saga 选择"先放行、错了再补"。最后 MVCC 回答一个看似在跑题的问题：这么多事务同时开，怎么让他们免排队、也互不干扰——答案是给每份数据留多版本。
沿途站点
- 5.1 一致性谱系：强、顺序、因果、最终四级，先给“一致性”分出层次，作为理解事务取舍的标尺。
- 5.2 两阶段提交：准备+提交两轮投票，用协调者换来"全或无"；也要看清它的阻塞与单点软肋。
- 5.3 三阶段提交：在 2PC 中间插一个"预提交"，把阻塞窗口缩短，代价是条件更苛刻。
- 5.4 补偿与 Saga：放下强一致，走"先执行+出错补偿"的软路线，给长事务一条活路。
- 5.5 MVCC：用多版本让读不挡写；顺带看它在分布式里的版本可见性与垃圾回收难题。
拐点与结论
本章最重要的认知转折是："跨节点原子性"不存在免费的午餐，越是硬保证，代价越堵。2PC 能给你最刚的"全或无"，但它阻塞、有协调者单点；3PC 想解决阻塞，条件又更苛刻；Saga/TCC 放弃强原子，换来可用与性能，但要靠业务自己写补偿。学完本章你应该明白：选哪种事务方案，本质是选"你愿意付出多少阻塞/复杂度，来换取多少一致性保证"，而没有哪个是万能答案。
读完你应该
- 分辨强、顺序、因果、最终一致四级各自的语义差异与适用边界。
- 完整复述 2PC 的准备/提交两阶段，并指出它的阻塞点与协调者单点。
- 说明 3PC 在 2PC 基础上加了什么、又付出什么代价。
- 给出补偿事务与 Saga 的核心流程，知道"谁负责补偿、谁保证顺序"。
- 描述 MVCC 如何实现"读不挡写"，以及它在分布式下新增的两道难题。
一句话记住每条路的代价
读完四个方案，把它们各自"锁死时怎么办"浓缩成四句话，用时直接对号：2PC 是"宁可憋住也要全结"——锁占着不放，协调者一宕大家都僵住；3PC 是"先统一口径再动作"——多一轮预提交，阻塞窗口变短但要参与者再多配合一步；补偿/Saga 是"先把事办了，错了我自己擦"——长期占用、等待被翻译成一步一步的业务动作与反动作；MVCC 是"不做报仇式等待，而是把历史留给后来者挑选"——读旧版本不必等写释放。记住这四句，遇到"我该用哪个"时，先问业务"你能接受多久的等待、多高的不一致"。
下一章的接力
事务要在一个"多台机器各执己见"的世界里分出对错，靠的是"大家听谁的"——这正是共识问题。第 6 章进入共识与容错，把 Paxos、Raft、Quorum、拜占庭容错与故障恢复逐一拆开。第 5 章埋的"协调者怎么可信"的疑惑，到第 6 章就有答案了。