分布式事务

什么是分布式事务？

在分布式系统中保证不同步节点的数据一致性

XA协议，包含两阶段提交（2PC）和三阶段提交（3PC）

1、2PC

第一阶段

事务协调者会像所有参与者发送prepare请求

参与者收到请求后，会执行与事务有关的数据更新，如果参与者执行成功，暂时先不提交事务，而是向协调者返回 ‘完成’消息

当时事务协调者收到消息，整个分布式事务进入到第二阶段

第二阶段

协调者向所有参与者发送commit请求

参与者收到请求后分别提交各自的本地事务，并释放资源锁，并向协调者发生完成消息

失败情况

如果在第一阶段，某个事物参与者返回失败，说明该事务参与者的本地事务执行失败

在第二阶段，协调者向所有参与者发送事务回滚请求，各个事务参与者节点需要在本地进行事务的回滚操作，回滚操作依照Undo Log来进行。

XA两阶段提交的不足

1.性能问题

XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。

2.协调者单点故障问题

事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。

3.丢失消息导致的不一致问题。

在XA协议的第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

2、3PC

XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。

原文链接：https://blog.csdn.net/bjweimengshu/article/details/79607522

3、TCC

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

TCC 是 Try、Confirm 、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm 、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm /Cancel 操作若执行失败，TM 会进行重试。

缺点：对代码入侵大

优点：2PC 通常都是在跨库的 DB 层面，TCC 则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

4、可靠消息最终一致性

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息（一定要发生出去），事务参与方（消息消费者）一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。（如果失败重试，要保证幂等）