两阶段提交简单来看就是coordinator向participant发出了两次命令,第一次是prepare,第二次是commit或者rollback。其中第一次的prepare相当于一次预演,在确保大家都能成功的情况下才会提交,从而避免了大家不一致的情况。为了让预演时成功就能在第二阶段成功,这要求participant在prepare后不能再修改。
三阶段提交时coordinator向participant发出了三次命令,第一次是canCommit,第二次是PreCommit或者abort,第三个是doCommit或者abort。在canCommit时准备了redo和undo,从而避免上面的阻塞状态,也就提高了吞吐能力。但是由于回滚的可能,那么就会出现脏读。
各种情况
coordinator 宕机
coordinator 卡
网络断开
网络卡
participant 宕机
participant 卡
不符合业务要求
资源不充分(比如硬盘被写满)
我们的目标是发生上面种种情况下仍然保持事务的一致性(当然,上面那些情况只能一致失败了)
状态的分类
状态有三类,一个是调用方从coordinator返回的状态Sr,第二个是整个集群的状态Sc,最后一个是单个participant的状态Sp。
Sp是单机状态,有两种情况SUCCESS,FIALURE.
Sc的情况复杂些,Sc其实是所有Sp的逻辑汇总,如果所有Sp的结果都一样那么Sc就和这个Sp一样,否则Sc就处于UNKNOW的状态
Sr是coordinator将Sc返回给调用方,如果能成功返回Sr就和Sc保持一致,否则Sr就处于UNKNOW的状态
状态的时机
当一个事务执行的过程中,如果这个时候有一个查询请求,那么可以在事务结束前查询到结果么?如果能够查询到结果,那么还会变更么?一般来说读到失败,那么最终应该也是失败。但是读到成功,最后可能会由于回滚而变成失败。participant可以在最终结果确定前拒绝其他请求从而屏蔽这种不稳定的状态,当是这是以降低系统的吞吐率作为代价的。
2PC
可以看出来如果出现了coordinator 宕机,coordinator 卡,网络断开,网络卡这些异常情况都归为FAILURE状态,从而避免Sr进入UNKNOW状态。另外决定SUCCESS的是所有participant(全量谓词),而FAILURE、UNKNOW可以由一个participant决定(存在谓词)。
3PC
对于3PC而言由于coordinator会有两次abort机会,所以这种出尔反尔的情况加大了participant的压力
对等vs非对等
对于participant而言,多个participant是接受同样的command并且是同样的顺序,将决定2PC的两种应用
在coordinator向不同的participant发送相同的commandC后,不同的participant也许会转化为相同的操作(operationC=operationY),也许不同。如果操作相同,并且没有其他的命令来源,那么dataX和dataY的数据是完全相同的,相当于这是个多副本的情况。如果X出了问题,Y可用则整个系统可以恢复,整个系统是一个高可用的架构。
另外participantX还可以接受到其他来源的commandX,转化为operationX。对于后者而言,dataX和dataY必然不同,这时如果participantX挂了,dataX丢失,是无法用dataY来恢复的,此时是为了让两个系统在某些数据上吻合,而无法达到高可用的结果,恰恰相反,此时是低可用的,因为任意一个participant宕机都导致整个系统不可用。