spring alibaba中的seata分布式事务

Seata AT 模式设计思路

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

核心在于对业务sql进行解决解析，转换成undolog，并同时入库存

二阶段：

提交异步化，非常快速地完成，则Tc通知RM异步删除undolog；

回滚一阶段日志进行反向补偿，tm向tc发送回滚请求，RM收一协调器TC发来的回滚请求，通过XID和Branch ID找到相应的回滚日志记录，通过回滚记录生成反向的更新sql并执行，以完成分支的回滚

两阶段提交协议(2PC)

阶段1：TM(事务管理器)通知各个RM（资源管理器)准备提交它们的事务分支

阶段2：TM 根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交;如果有RM prepare失败的话，则TM通知所有RM回滚自己的事务分支。

存在的问题：

1. 同步阻塞问题
2. 单点故障
3. 数据不一致

XA模式

执行阶段：

可回滚：业务SQL操作放在XA分支中进行，由资源对XA协议来保证可回滚

持久化：XA分支完成后，执行XA prepare，同样，由资源对XA协议的来支持来保证持久化

完成阶段：

分支提交：执行XA分支的commit

分支回滚：执行XA分支的rollback

TCC模式

tcc基于分布式事务中的二阶段提交协议实现，这化的全称为Try-Confirm-Cancel，即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel)，他们的具体含义如下：

1. Try：对业务资源的检查并预留
2. Confirm:对业务处理进行提交，即commit操作，只要Try成功，那么该步骤一定成功
3. Cancel：对业务处理进行取消，即回滚操作，该步骤回对Try预留的资源进行释放。

TCC是一种侵入式的分布式事务解决方案，对业务系统有着非常大的入侵性，设计相对复杂

优点：TCC完全不依赖数据库，能够实现跨数据库、跨应用资源管理

Seata如何防止空回滚，新增一个TCC事务控制表

如何处理幂等，幂等问题指的是 TC 重复进行二阶段提交，因此 Confirm/Cancel 接口需要支持幂等处理，即不会产生资源重复提交或者重复释放。

如何处理悬挂，在 TCC 事务控制表记录状态的字段 status 中增加一个状态： 当执行二阶段 Cancel 方法时，如果发现 TCC 事务控制表没有相关记录，说明二阶段 Cancel 方法优 先一阶段 Try 方法执行，因此插入一条 status=4 状态的记录，当一阶段 Try 方法后面执行时，判断 status=4 ，则说明有二阶段 Cancel 已执行，并返回 false 以阻止一阶段 Try 方法执行成功

XA与TCC比较

1. XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

1. TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁

AT模式与TCC模式比较

区别在于：

AT模式基于支持本地ACID事务的关系型库数据

一阶段prepare行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录

二阶段commit行为：马上成功结束，自动异步批量清理回滚日志

二阶段rollback行为：通过回滚日志，自动生成补偿操作，完成数据回滚

相应用的，TCC模式不依赖于底层数据资源的事务支持：

一阶段prepare行为：调用自prepare逻辑

二阶段commit行为：调用自定义的commit逻辑

二阶段rollback行为：调用自定义的rollback逻辑。

简单点概括，SEATA的TCC模式就是手工的AT的模式，它允许你自定义两阶段的处理逻辑而不依赖AT模式的undo_log

可靠消息最终一致性

异步化在分布式系统设计中随处可见，基于消息队列的最终一致性就是一种异步事务机制，在业务中广泛应用。

本地消息表

将分布式事务拆分成本地事务进行处理，通过消息日志的方式来异步执行。本地消息表是一种业务耦合的设计，消息生产方需要额外建一个事务消息表，并记录消息发送状态，消息消费方需要处理这个消息，并完成自己的业务逻辑，另外会有一个异步机制来定期扫描未完成的消息，确保最终一致性。

RocketMQ事务消息

RocketMQ事务消息是一种支持分布式事务的消息。它通过引入prepare、commit和rollback三个阶段，来确保事务消息的一致性。

1. Prepare阶段：消息发送方发送消息，此时消息的状态为“待提交”
2. commit阶段：消息发送方向RocketMQ发送commit消息请求，RocketMQ判断此时半消息是否被确认，如果半消息已被确认，则将消息标记为“可消费”并提交事务。如果半消息未被确认，刚将消息标记为“不可消息”并终止事务。
3. rollback阶段：消息发送方向rocketMQ发送rollback消息请求，RocketMQ将半消息标记为“不可消费”并回滚事务。

最大努力通知

最大努力通知型是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理不影响主动方的处理结果。

最大努力通知实施方案，一般符合以下特点：

1. 不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失（不可靠消息）
2. 定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询（主动方提供查询接口），恢复丢失的业务消息