处理分布式事务一致性的方法

1.两阶段提交

这里只写原理，不谈具体实现过程。

首先需要两个载体，一个是事务提交者，一个是协调器。

   第一阶段：

协调器向所有的事务提交者发起询问，是否可以执行本地事务。

不同的事务提交者在本地执行事务，执行成功向协调器发送成功，失败则发送失败（超时也算失败）。

   第二阶段：

协调器如果在第一阶段收到失败，则通知所有事务提交者进行rollback操作。如果没有收到失败则向事务提交者发送可以进行提交。

事务提交者提交事务，释放资源，并向协调器发送成功，如果是回滚成功，则发送回滚成功。

协调器收到回信后，结束事务。（未收到回信，例如commit没有传到事务提交者也结束，所以有很大缺点）

2.三阶段提交

第一阶段：

协调器向所有的事务提交者发起询问，是否可以执行本地事务。

事务提交者认为可以执行则发送true，不可以则发送false（或者超时）。

第二阶段：

如果协调器收到false，则中断事务并发送中断请求，全部收到true，则向事务提交者发送可以准备执行事务的信息。

事务提交者（未收到或者超时或者收到中断请求，执行事务的中断）收到可以准备执行时，会执行事务操作，

成功执行会向协调器发送true，失败返回false。

第三阶段：

协调器收到二阶段全为true时，向事务提交者发送可以提交，否则发送回滚（未收到或者超时也回滚）。

事务提交者收到可以提交，提交事务，返回成功（如果超时未收到依然提交事务）。收到回滚，则回滚事务，发送回滚成功。

协调器收到所有的提交事务成功，结束事务，收到回滚成功，中断事务。

三阶段加入了超时机制，但仍无法完全解决一致性问题，因为在三阶段时，发生超时情况，事务会默认提交。

3.消息事务（性能高）

基于消息中间件的分布式事务。（要支持本地执行和消息发送是原子性的，也可以使用别的方法来实现，使用日志或者状态表）

最简单的，事务A执行完本地事务后，向消息队列发送消息，消息中间件提醒其他事务完成剩余的操作。

但是需要很多的手段来确保事务的最终一致性，直接使用分布式事务性能低，但开发难度小。

4.Paxos算法

还没看明白