分布式事务解决方案整理
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 不断回调直至成功，或直至调用次数衰减至失败状态.
适用于异构/平台之间对接，比如支付回调。