摘要
- 参与者只有在保存了足以重做或撤销本地工作的持久状态后才投赞成票;这张票限制了它单方面退出的自由,却没有产生全局提交决定。
- 协调者的持久决定是另一项协议事实。prepared 参与者若无法获知它,等待比把未知状态擅自改写成提交或中止更安全。
- 提交约束的是加入事务的资源管理器;它不证明邮件、人工任务、出钞设备或其他外部动作已经且仅执行一次。
设想一台参与服务器从故障中恢复:本地计算成功,日志里有强制写入的 prepare 记录,它也记得自己投过赞成票,唯独没有收到最终决定。把它叫作“差一点就提交”会误导值班人员。准确的状态是 prepared,也就是已准备、待裁决。
Jim Gray 关于事务处理的论述,让这一区别成为一种可靠的推理方法。第一阶段建立执行两种结果的能力,并把参与者约束在承诺之中;第二阶段才交付一个来自有权决定者的持久结果。
prepare 记录是一份承诺收据
Gray 1978 年的《Notes on Data Base Operating Systems》写道,协调者要求每个参与者进入一种无论后来发生什么,都能重做或撤销其工作的状态。参与者在回复 AGREE 之前,必须把需要的 UNDO 与 REDO 信息放进安全存储。
赞成票因此不等于庆祝本地成功。投票以前,参与者还能拒绝并中止;投票以后,它必须保留日志、锁或版本,使提交和中止两条路都仍然可走。承诺越可靠,单方面行动的自由反而越少。
C. Mohan、Bruce Lindsay 与 Ron Obermarck 在 IBM R* 系统的论文中把边界写得很明确:下级节点强制写入 prepare 记录,发送 YES,进入 prepared 状态,此后不得自行提交或中止。协议把“本地已完成”改造成“有条件地服从”,而不是“全局已经完成”。
提交点在另一份持久记录上
协调者收集所有必需的投票。只有满足协议条件后,它才强制写入全局 commit 记录,再向参与者广播结果。R* 论文把这次写入称为提交点。因此,任何一名参与者的 YES 都必然早于它需要执行的最终事实。
这个次序阻止多个本地成功变成多个互相冲突的真相。若一名参与者把自己的赞成票当成提交,而另一名参与者在准备之前失败,前者可能暴露后者必须撤销的效果。两阶段的意义,正是让各地的准备能力服从同一个持久决定。
即使某个参与者知道其他人都已赞成,它也不一定拥有协调者的决策权限。关于投票的信息与建立结果的权力不是同一回事。恢复过程要找回真实裁决,而不是计算“最可能发生了什么”。
恢复重建的是协议知识
Gray 给出的恢复规则非常克制。找不到强制写入的 agreement 记录,参与者可以中止,因为持久承诺尚未对外成立;找到记录,就必须向协调者或获授权的恢复路径询问结果,再据此执行 REDO 或 UNDO。日志回答的是“我承诺了什么”,不是“我希望结果是什么”。
因此,运维界面必须把 working、prepared/in-doubt、committed 与 aborted 分开。若把 prepared 和 committed 合并成“成功”,最关键的不确定性反而被隐藏。此时服务可以完全健康,本地数据也完好无损,全球结果却仍未知。
有价值的证据包括事务标识、协调者或恢复权威、prepare 的持久化时间、最后一次确认联络,以及仍被占用的锁和版本。简单重跑业务动作并不能解决旧事务的身份,反而可能制造第二次副作用。
阻塞是拒绝编造决定的代价
协调者在收到 YES 后失效,而参与者尚未得到结论,经典两阶段提交就可能阻塞。Gray 与 Leslie Lamport 后来的《Consensus on Transaction Commit》直接以此为出发点:单一协调者足以推动正常路径,但它的故障会令协议停住。
等待并不轻松。锁继续占用,容量无法释放,后续请求堆积。但它诚实表达了两件事:参与者既不知道决定,也无权自己创造决定。擅自提交可能导致各节点结果分裂;擅自中止则可能反对已经在别处持久化的 commit。
R* 论文讨论了极端情况下的启发式人工裁决,也警告它可能与真实全局决定冲突。这样的处置应被标记为对正常一致性保证的例外,并启动核对与修复;它不是把 2PC 变成非阻塞协议的捷径。
事务边界不会自动包住现实世界
Gray 1981 年的《The Transaction Concept: Virtues and Limitations》区分了受保护动作与“现实动作”。日志可以还原数据库状态,却不能收回已经吐出的现金、撤回已经送达的邮件、逆转人的决定,也不能让一个未加入事务的设备天然做到恰好一次。
外部效果需要自己的设计:等提交后再触发、使用幂等键、先记录一项可持续投递的请求,或设计补偿动作。补偿是一次新的业务行为,不是完美倒放的 rollback。
于是,数据库可以如实显示 committed,而消息仍可能待发送、重复或失败;也可能设备已经动作,数据库随后却中止。把两边都压成一个“完成”状态,只会掩盖影响机制。正确做法是分别记录事务裁决与外部效果的证据。
这段历史不属于单一发明者
本文以 Gray 的解释为中心,却不能把他写成两阶段提交的唯一发明者。他在 1978 年的历史说明中提到 Ron Obermarck、Earl Jenner、Steve Weick 的早期工作,也明确说 Butler Lampson 与 Howard Sturgis 独立发现了 2PC。Mohan、Lindsay 和 Obermarck 共同撰写 R* 论文及其优化;Andreas Reuter 与 Gray 合著后来的经典教材,Leslie Lamport 则与他共同提出 Paxos Commit 的论述。
保留这些署名边界,技术结论反而更清楚。Gray 在这里留下的持久价值,是要求系统分别回答:它知道什么、它已承诺什么、谁有权决定,以及哪些后果仍在事务控制之外。
来源
- Jim Gray,《Notes on Data Base Operating Systems》(1978)
- Jim Gray,《The Transaction Concept: Virtues and Limitations》(1981)
- C. Mohan、Bruce Lindsay、Ron Obermarck:R* 分布式事务管理
- Jim Gray、Andreas Reuter,《Transaction Processing: Concepts and Techniques》
- Jim Gray、Leslie Lamport,《Consensus on Transaction Commit》
- Microsoft Open Specifications:两阶段提交阶段说明
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
