浅谈两阶段提交和三阶段提交

本文主要分为三个部分

第一部分阐述两阶段提交的原理和优缺点。

第二部分阐述三阶段提交的原理和优缺点。

第三部分阐述如何解决业务中最终一致性的问题。

 

一.两阶段提交

两阶段提交方法是用于分布式事务中用来完成事务操作的。

 

两阶段提交是一种思想，XA协议，TCC，Paxos，Raft都用到了这种思想。

 

这里先基于XA协议谈一下，因为我们一般提到的两阶段提交都是基于XA协议。

 

两阶段提交分为投票和提交两个阶段。

投票阶段，协调者向参与者发送事务请求，参与者进行操作并记录进日志，但不提交，并将操作结果通知协调者。

提交阶段，协调者收到参与者的操作结果后，如果都是成功的，就通知参与者提交。如果有不成功，就通知参与者回滚。

 

它的优点是原理简单，实现方便。

它的缺点是会出现单点故障，同步阻塞，数据不一致的问题。

 

由于XA协议会在第一阶段就锁定资源，所以会有一些性能问题。

 

同样运用到两阶段提交思想的TCC协议，则针对性能做了一些提升。

 

TCC也是一种两阶段提交方法，它的全称是Try，Confirm，Cancel。它分为预留阶段和确认阶段，预留阶段参与者要实现事务操作，确认和撤销操作。确认阶段，如果所有参与者确认成功，就确认操作，否则就实现撤销操作。

 

它是通过业务代码来实现的 。它本质上是一种补偿事务，就是他为每一个操作都注册一个确认和撤销的操作。这样可以减轻数据库压力，可以提升并发性能。

 

通俗的讲TCC协议就是把出现成功和失败后的应对操作都考虑到了，并用业务代码编写。

 

另外，两阶段提交会出现数据不一致的问题。

在第二阶段进行提交时，如果这时发生网络故障或者协调者发生了故障，导致只有一部分参与者收到消息进行提交，这时这个分布式系统就会出现不一致的问题。

 

二.三阶段提交

这时候又出现了三阶段提交方法，三阶段提交在二阶段提交的基础上引入了超时机制和准备机制，解决同步阻塞和改进数据不一致性的问题。

 

第一步

协调者向参与者询问是否可以执行事务操作。

 

第二步

协调者在得到参与者的回复后决定是否进行预提交。

如果进行预提交，参与者执行事务操作，记录事务日志，返回操作结果给协调者。

如果不进行预提交，参与者收到不提交的消息或者超时未接收到协调者的消息或者协调者没有收到参与者的响应，就中断事务操作。

 

第三步

协调者发送命令给所有参与者，执行提交或中断操作。

如果执行提交操作，参与者收到消息后正式提交事务，提交事务后，向协调者发送确认响应，协调者收到所有确认响应后，完成事务。

如果执行中断操作，参与者收到消息根据在预提交阶段记录的日志进行回滚，回滚后向协调者发送确认响应，协调者收到所有确认响应后，中断和结束事务。

 

三阶段提交的优点是解决了二阶段提交方法同步阻塞的问题，改善了二阶段提交的数据不一致性的问题。

 

三阶段提交的缺点和二阶段一样：

1.需要锁定资源，会降低系统性能。

2.仍然存在数据不一致性的问题，三阶段在最后提交阶段，如果协调者发出的中断命令，由参与者没有收到，参与者在超时后会自动提交事务，造成了数据不一致性。

 

三.既然两阶段提交和三阶段提交都是强一致性，怎么解决业务中的最终一致性问题？

通过分布式消息来确保事务最终一致性。

在 eBay 的分布式系统架构中，架构师解决一致性问题的核心思想就是：将需要分布式处理的事务通过消息或者日志的方式异步执行，消息或日志可以存到本地文件、数据库或消息队列中，再通过业务规则进行失败重试。

另外，建议在开发实现分布式系统，如果不是必须，尽量不要实现事务(ACID)，可以考虑采用强一致性(两阶段提交和三阶段提交)或最终一致性。

 

参考

1.极客时间 《分布式技术原理与算法解析》

2.极客时间 《分布式协议与算法实战》