本文梳理分布式系统中的常见概念:二阶段提交协议和三阶段提交协议。
二阶段提交协议(Two-phase Commit Protocol)
TPC是基于分布式系统架构下所有节点进行事务提交时保持一致性而设计的一种算法。在分布式系统中,每个节点虽然可以知晓自己操作的成功或失败,但无法知道其他节点的情况。需要一个协调者来组织所有节点的操作结果并最终指示他们是否进行真正的提交。
第一阶段:投票阶段
1)协调者给参与者发送信息,询问是否vote,等待响应。
2)参与者节点执行事务操作,写本地的redo和undo日志,但不提交。
3)参与者回复协调者,如果实务操作执行成功,返回“同意”。否则,返回“中止”。
第二阶段:提交阶段
a.如果第一阶段所有参与者提交都为“同意”:
1)协调者给参与者发送“是否正式提交”的询问。
2)参与者正式完成操作,释放资源。
3)参与者返回“完成”信息。
4)协调者收到所有“完成”信息,完成事务。
b.如果第一阶段有参与者提交“中止”:
1)协调者向所有参与者节点发出“回滚”的请求。
2)参与者利用undo信息执行回滚,释放在整个事务占用的资源。
3)参与者返回“回滚完成”信息。
4)协调者收到所有参与者的“回滚完成”后,取消事务。
整个过程如图所示:
存在的问题
- 节点在等待消息处于阻塞的状态,节点中的其他进程需要等待阻塞进程释放资源。
- 如果参与者故障,协调者需要给每个参与者制定超时机制,超时后整个事务失败。TPC没有容错机制,一个节点故障整个事务都要回滚,代价很大。
- 如果协调器发生故障,参与者无法完成事务,就会一直阻塞下去。
- 如果协调者发出commit消息之后宕机,唯一接收到消息的参与者也同时宕机了,即使协调者通过选举产生了新协调者,这条事务的状态是无人知晓的。
因此,后来产生了三阶段提交协议。
三阶段提交协议(Three-phase Commit Protocol)
非阻塞协议。
两方面的改动:
- 引入超时机制,协调者和参与者都引入超时机制。
- 在TPC的第一阶段和第二阶段之间插入了一个准备阶段,保证在最后提交阶段之前各参与节点的状态是一致的。
References:
- 3.1.4 Two-phase commit: http://itdoc.hitachi.co.jp/manuals/3000/30003D5030e/DESC0050.HTM
- Wikipedia:
https://zh.wikipedia.org/zh-hans/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4 - 分布式协议之两阶段提交协议(2PC)和改进三阶段提交协议(3PC): http://www.mamicode.com/info-detail-890945.html