分布式事务解决方案：二段式和三段式提交协议

在一些面试中，面试官比较喜欢提问：如何保证分布式事务？比较出名的解决办法就是二段式提交协议、三段式提交协议和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消息，然后网络出现问题，参与者和协调者无法通信，这种情况下，参与者依然会执行事务的提交。