二段式提交和三段式提交

CAP定理

2000年7月加州大学伯克利分校 Eric Brewer教授提出CAP猜想，两年后被证明。

CAP理论告诉我们，一个分布式系统不可能同时满足一致性（C，Consistency），可用性（A，Availability）和分区容错性（P，Partition tolerance）三个基本要求，最多只能同时满足其中两个。

一致性：分布式系统中，能够做到针对一个数据的更新成功后，其他所有的用户都可以读取到［最新的值］，那么这样子的系统就是强一致性的。

可用性：［有限时间内］［返回结果］

分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够抱枕固堤外提供满足一致性和可用性的服务。

其实CAP定理是理论，现实系统场景中的CAP也不一定会真的会放弃其中一个不做，而是我们可以着重性的保证其他两个，而剩下的一个尽量保证。

 

在一些面试中，面试官是比较喜欢提问到如果保证分布式事务的。比较出名的解决办法就是二段式提交协议、三段式提交协议和Paxos算法了。

［二段式提交协议］是将事务的提交过程分成了两个阶段来进行处理，其执行过程如下：

阶段一：提交事务请求：

    1、事务询问。协调者向所有参与者发送事务内容，询问是否可以进行事务提交操作，然后就开始等待参与者的响应。

    2、执行事务。各参与者节点执行事务奥做，并将Undo和Redo信息记入事务日志中。

    3、各参与者向协调者反馈事务询问的响应。

阶段二：执行事务提交：

    假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。

    1、发送提交请求。

    2、事务提交。

    3、反馈事务提交结果。参与者在完成事务提交之后，会向协调者发送Ack消息。

    4、完成事务。

    中断事务：

    1、发送回滚请求。协调者向参与者发出rollback请求。

    2、事务回滚。参与者接收到Roolback请求利用阶段一种记录的Undo信息来执行事务回滚动作。

    3、反馈事务回滚结果。

    4、中断事务。

 

二段式提交协议的优缺点：

优点：原理简单，实现方便；

缺点：同步阻塞、单点问题、脑裂（比如协调者的消息在网络异常情况下只给一部分参与者发送了）、太过保守。

 

［三段式提交协议］其实是在二段式基础上面针对二段式的缺点进行了改进。

阶段一：CanCommit

    1、事务询问。

    2、各参与者向协调这反馈事务询问的响应。

阶段二：PreCommit

    假设协调者从所有的参与者获得的都是Yes响应，那么将执行事务预提交。

        1、发送预提交请求。协调者向所有参与者节点发出preCommit请求，进入prepared阶段。

        2、事务预提交。参与者接收到preCommt请求，执行事务擦偶走，将Undo和Redo信息记录到事务日志中。

        3、各参与者向协调者反馈事务提交的响应。

    假设任何一个参与者向协调者反馈了No反应，活着在等待超时之后，协调者无法获得所有参与者的响应，那么将执行事务的中断。

        1、发送终端请求。协调者向所有参与者发出abort请求。

        2、中断事务。无论接到abort请求还是等待协调者请求过程出现超时情况，参与者都会中断事务。

阶段三：doCommit

该阶段将进行真正的事务提交：

    执行提交

        1、发送提交请求。进入这一阶段，假设协调者从正常的工作状态，并且接收到所有的参与者的ack响应，它将从预提交状态转换到提交状态，向所有参与者发送doCommit请求。

        2、事务提交。参与者接收到doCommit请求后，正式执行事务提交操作。并在提交后释放在整个事务执行期间占用的事务资源。

        3、反馈事务提交结果。参与者完成事务提交之后，向协调者发送Ack消息。

        4、完成事务。协调者接收到所有参与者的Ack消息，完成事务。

    中断事务

        中断事务的4步操作与提交事务完全一致，只不过从提交事务变成了事务回滚。

三段式提交协议的优缺点：

最大优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

缺点就是在去除阻塞的情况下引入了新的问题，那就是参与者接收到了PreCommit消息，然后网络出现问题，参与者和协调者无法通信，这种情况下，参与者依然会执行事务的提交。

 

－－－－

该文内容出自倪超的《从Paxos到zookeeper》