分布式事物处理机制

本文介绍了XA协议的两阶段提交方案及其实现原理,并分析了其在微服务场景下的局限性。此外还探讨了TCC方案的具体实现过程,包括Try、Confirm、Cancel三个阶段的操作流程,以及基于消息的最终一致性方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

XA协议的两阶段提交方案

第一阶段是表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;第二阶段是执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚。

但是两阶段提交方案锁定资源时间长,对性能影响很大,基本不适合解决微服务事务问题。

 TCC方案

其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。

事务开始时,业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口,完成一阶段准备。之后事务协调器会根据try接口返回情况,决定调用confirm接口或者cancel接口。

基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息,收到消息后执行相应操作。

GTS--分布式事务解决方案

GTS目前有三种输出形式:公有云输出、公网输出、专有云输出。

 

转载于:https://www.cnblogs.com/facker1/p/10607349.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值