两阶段提交协议
定义 :
在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的算法
情景
在分布式系统中,每个节点虽然可以知道自己的操作是否成功,却无法知道其他节点是否成功,当一个事务跨越多个节点时,为了保持事务了ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交
算法思路
参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报来决定各参与者是否要提交操作还是中止操作
操作流程
-
准备阶段
协调者给每个参与者发送Prepare消息,每个参与者要么直接返回失败,要么在本地执行事务,写本地的 redo 和 undo 日志,但不提交
- redo
redo日志用于存放数据修改后的记录,顺序记录 - undo
undo日志用于存放数据修改之前的值
- redo
-
提交阶段
如果协调者收到了参与者(某个)的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息,否则发送提交(Commit)消息,参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源(必须是在最后阶段释放锁资源)
缺点
-
同步阻塞问题
执行过程中所有参与节点都是事务阻塞型的
-
单点故障
一旦协调者发生故障,参与者接收不到commit或者rollback消息,参与者会一直阻塞下去
-
数据不一致(脑裂问题)
在提交阶段中,当协调者向参与者发送commit请求后,发生了局部网络异常或在发送commit请求过程中协调者发生故障,导致只有一部分参与者接收到了commit请求,于是整个分布式系统便出现了数据不一致的现象
-
数据状态不确定
协调者在发出commit消息之后宕机,而唯一接收到这条消息的参与者也同时宕机,那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没有人知道事务是否已经提交
三阶段提交协议
是对二阶段提交的改进版本 :
-
引入超时机制,同时在协调者和参与者中都引入了超时机制
-
在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说,除了引入超时机制之外,3PC 把 2PC 的准备阶段再次一分为二,这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。
操作流程
-
CanCommit阶段
协调者向参与者发送 commit 请求,参与者如果可以提交就返回 Yes 响应,否则返回 No 响应
-
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以继续进行。
有以下两种可能 :
1、假如协调者从所有的参与者获得的反馈都是 Yes 响应,那么就会执行事务的预执行。
2、假如有任何一个参与者向协调者发送了 No 响应,或者等待超时之后,协调者都没有接到参与者的响应,那么就执行事务的中断。 -
DoCommit阶段
该阶段进行真正的事务提交,主要包含 1.协调这发送提交请求 2.参与者提交事务 3.参与者响应反馈( 事务提交完之后,向协调者发送 Ack 响应。)4.协调者确定完成事务。