分布式事务

第一阶段

T3

可以看到通过代理来无侵入的得到数据的前后镜像，组装成回滚日志伴随本地事务一起提交，解决了两阶段的同步阻塞问题并且利用全局锁来实现写隔离。为了总体性能的考虑，默认是读未提交隔离级别，只代理了 SELECT FOR UPDATE 来进行读已提交的隔离。

都成功

参与者

AT模式（2PC）

事务协调者

大胆往前执行，失败的时候，从失败位置开始补偿回滚。

本地事务操作

回滚阶段

准备阶段

分布式事务整体方案

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

下一个服务

Try

TCC

本地消息表

ConFirm

C3

Try：和2PC的准备阶段不同，这里做了业务外的操作，只做部分资源的准备。比如转账前的资金冻结。Confirm：具体执行业务Cancel：就是对try留下的部分影响进行清除。整体上TCC是一个精心设计的2阶段事务方案，针对业务进行设计。TCC的注意事项1. 幂等实现：网络的不可靠性，通过重试是最简单的方式，所以设计幂等针对这3个操作，可以有效保证执行的可靠性。2. 空回滚问题：try没执行就收到cancel命令。需要正确再无try的情况下执行cancel3. 悬挂问题：参与者先收到cancel，后收到try命令，此时的try命令不能执行。因此TCC设计有个共同点，2阶段三种操作应该有个严格的状态转换机。且在这个状态机的操作基础上实现幂等操作。针对业务功能设计。

Lock（guid@data1）

提交/回滚阶段

回滚命令

cancel失败则提供证据人工干预

第二阶段

预提交阶段

没有try的TCC

AP应用程序：事务的发起者RM资源管理器：简单的认为是数据库，具备事务提交和回滚能力。对应上面的参与者。TM事务管理者：协调者，和每个RM通信。从模型上看有三个角色，实际上可以让AP来实现TM的功能。TM没必要抽出来单独部署。

优点：2PC 的优点是能利用数据库自身的功能进行本地事务的提交和回滚，也就是说提交和回滚实际操作不需要我们实现，不侵入业务逻辑由数据库完成，在之后讲解 TCC 之后相信大家对这点会有所体会。缺点：1. 同步阻塞第一阶段执行了准备命令后，每个本地资源都处于锁定状态。会导致并发访问锁定。效率低。2. 单点故障单点就是协调者，如果协调者挂了整个事务就执行不下去了。尤其是当准备阶段后事务协调者挂了，则会很多锁定资源，更严重。3. 数据不一致问题提交阶段没有保障所有节点一致性的能力。可能部分节点收到消息，部分节点没有收到消息，导致数据不一致。

Seata的实现

XA规范

T4

有一个失败

Cancel

有一个失败的时候都执行cancel

同一个事务

将一个TCC业务封装成一个Business Endpoint

TCC对业务侵入很强，但涉及到第三方系统无法控制的时候会出现没有try的情况下，直接执行confirm，失败了需要执行cancel。在这种情况下一般业务设计步骤是：

data2

事务最终一致性线程

TCC模式

相当于TCC的一个改进版，主要应用于长事务的情况下。先多次提交，失败后多次补偿

事务消息

Confirm

MySql的XA是2PC的具体落地实现。性能不高。

confirm

Saga

AT

定时扫描

2PC（Two-phase commit protocol）

OK

3PC引入一个阶段，在极端情况下会体现优势。但大部分情况下仍然是多了一次开销。数据不一致问题没有实质上的解决。

就是一个询问阶段

分布式数据库的 2PC 改进模型（Percolator 模型）

提交阶段

Mysql XA

Lock（guid）

Normal transactions

和本地消息类似，将本地事务操作和发消息放在一个事务中。只是这本身需要应用分布式事务来保证一致性。再由消息队列来完成后续业务执行。保证本地事务提交和发消息的原子性，借助两阶段提交和TCC完成，在幂等的情况下通过多次发送补偿。

Saga模式

分布式事务

1. 事务管理器还记录下这次操作的日志2. 此时的数据还是私有版本，别的事务是读不到的，简单地理解 Lock 上有值就还是私有的3. Lock上的标记“pk”是随机的，估计还有全局唯一性。来保证多次事务之间的隔离性4. 事务管理器会向被选择作为 PK 的那条记录发起提交指令。此时lock标记会小时，表示提交成功。数据公有化5. 找到机会关联lock的记录会消除lock，判断依据就是关联的lock已经提交。时机可能是请求的时候，也可能是后端线程清理。优点：1. 提交阶段只和一个参与者交互，可以保证原子性，从而达到数据一致性要求。2. 事务管理器记录日志，为多节点转移故障做好准备。可以解决单点故障问题。

执行成功，调用（不一定调用成功）

RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交

C2

总结

准备命令

Seata

本地消息

分布式数据库对2PC的改进

XA

根据需要调用，完成最终事务一致性

通用TCC

TCC 就是一种业务层面或者是应用层的两阶段提交TCC分别指代Try、Confirm、Cancel。主要用于跨数据库、跨服务的业务操作的数据一致性问题。

事务管理器

3PC

提交命令

常见实现方案

1. 上面所有方案都只保证了一个事务内的原子性，都执行或都不执行。并且部分模式还不能完全保证。2. 分布式事务没有很好的保证事务的隔离性。如TCC还有saga模式，都先提交了事务，也就是隔离级别基本在读未提交这个级别。3. 分布式事务很难。4. 考虑业务是否需要分布式事务，尽量不用分布式事务5. 认真设计，减小分布式事务的执行范围，让尽量小的数据执行分布式事务。其他业务依赖这部分事务来做到最终一致性。6. 做好链路跟踪、日志记录。极端情况下需要人工介入。

AP

Percolator 模型，它是基于分布式存储系统 BigTable 建立的模型

2PC、3PC

T2

kafka

data1

没有Try的TCC

RocketMQ

准备

Compensating transactions

T1

这个阶段会进行锁表，不提交事务

 XA 约束下的 DTP 模型

异步型TCC

Fails

C4

RM

本地消息插入

TCC总结：1. 业务侵入很高2. 性能比2PC要高，因为没有资源阻塞。

关联

TM

分布式事务框架

Percolator模型

C1