1.解决方案
1.1 全局事务
全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型--X/Open
Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色:
- AP: Application应用系统(微服务)
- TM: Transaction Manager事务管理器(全局事务管理)
- RM: Resource Manager资源管理器(数据库)
整个事务分成两个阶段: - 阶段一:表决阶段，所有参与者都将本事务执行预提交，并将能否成功的信息反馈发给协调者。
- 阶段二:执行阶段，协调者根据所有参与者的反馈,通知所有参与者，步调一致地执行提交或者回滚。
1.2 可靠消息服务
基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。
假设有A和B两个系统，分别可以处理任务A和任务B。此时存在一个业务流程， 需要将任务A和任务B在同一个事务中处
理。就可以使用消息中间件来实现这种分布式事务。
1.事务消息发送及提交
(1)发送消息(half消息)
(2)服务端响应消息写入结果
(3)根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可见，本地逻辑不执行)
(4)根据本地事务状态执行Commit或者Rollback(Commit操作生产消息索引，消息对消费者可见)
2.事务补偿
(1)对没有Commit/Rollback的事务消息(pending状态的消息),从服务端发起一次回查”
(2) Producer收到回查消息，检查回查消息对于的本地事务的状态
(3)根据本地事务状态，重新Commit或者Rollback
其中，补偿阶段用户解决消息Commit或者Rollback发生超时或者失效的情况
3.事务消息状态
事务消息共有三种状态，提交状态，回查状态，中间状态:
- TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息
- TransactionStatus.RollbackTransaction: 回滚事务，它代表消息将被删除，不允许被消费
- TransactionStatus.Unknown:中间状态，它代表需要消息队列来确认状态
1.3 TCC事务
TCC即为Try Confifirm Cancel,它属于补偿型分布式事务。TCC实现分布式事务一共有三个步骤:
- Try: 尝试待执行的业务
这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源 - Confifirm: 确认执行业务
确认执行业务操作，不做任何业务检查，只使用Try阶段预留的业务资源。 通常情况下，采用TCC
则认为Confifirm阶段是不会出错的。即:只要Try成功, Confifrm- -定成功。若Confifirm阶段真的
出错了,引入重试机制或人工处理。 - Cancel: 取消待执行的业务
取消Try阶段预留的业务资源。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。 若
Cancel阶段真的出错了，引入重试机制或人工处理。
TCC事务的优缺点:
- 优点:把数据库层的二阶段提交上提到了应用层来实现，规避了数据库层的2PC性能低下问题。
- 缺点:TCC的Try、Confifirm和Cφncel操作功能需业务提供，开发成本高。
1.4 TTC异常处理
-
空回滚
Try方法未执行,Cancel执行了
出现原因:
1.Try超时
2.分布式事务回滚,触发Cancel
3.未收到Try,收到Cancel
解决方案: Cancel方法需要识别出是否执行Try方法，如果执行了就正常执行Cancel,如果没有就直接结束
增加事务日志表来实现这个功能
-
幂等
多次调用二阶段方法
出现原因:
●网络异常
●分支事务所在服务器宕机
解决方案:做幂等性处理
-
悬挂
1.5 TTC流程
