分布式事务解决方案整理

1.2PC/3PC模式

1.1 介绍：

依赖资源管理器(mysql, redis)支持XA协议，

数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务,

所有结点要么全做要么全不做。

1.2 特点:

需要依赖资源管理器RM(数据库)对XA的支持。

整个处理过程需要锁住事务资源，性能比较低。

场景一：

1）协调者节点向所有参与者节点发出”正式提交(commit)”的请求。

2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。

3）参与者节点向协调者节点发送”完成”消息。

4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。

场景二：

1）协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。

2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。

3）参与者节点向协调者节点发送”回滚完成”消息。

4）协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。

2. TCC模式

2.1介绍

2PC的另类实现，TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑的调度来实现分布式事务，

在业务中新增确认和取消的业务接口;主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

2.2 特点

该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。

该模式对有无本地事务控制都可以支持使用面广。

数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。

3. TXC模式

3.1 介绍

TXC模式命名来源于阿里云的GTS，实现原理是在执行SQL之前，先查询SQL的影响数据保存起来然后再执行业务。当需要回滚的时候就采用这些记录数据回滚事务。

3.2 特点

该模式同样对代码的嵌入性低。

该模式仅限于对支持SQL方式的模块支持。

该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。

该模式不会占用数据库的连接资源。

4. LCN模式

4.1 介绍

LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。

4.2 特点

该模式对代码的嵌入性为低。

该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。

该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。

该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。

5.其他解决方案

4.1 本地事务+MQ:采用时效性高的MQ，由对方订阅消息并监听，有消息时自动触发事件;用定时轮询扫描的方式，去检查消息表的数据。

4.2 不断回调直至成功，或直至调用次数衰减至失败状态.

适用于异构/平台之间对接，比如支付回调。