从Paxos到Zookeeper（二）Two-Phase Commit & Three-Phase Commit

两阶段提交简单来看就是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宕机都导致整个系统不可用。