分布式事务解决方案

本文介绍了分布式事务的几种解决方案,包括基于XA协议的两阶段提交(2PC)、代码补偿事务(TCC)以及本地消息表实现的事务最终一致性。2PC在保证强一致性的同时存在效率问题,而TCC通过业务层面的尝试、确认和取消操作实现最终一致性,减少资源锁定。本地消息表则通过异步确保事务的一致性,但可能引入额外的复杂性和延迟。
摘要由CSDN通过智能技术生成

1.基于XA协议的两阶段提交(2PC)

XA协议:XA是一个分布式事务协议。XA中大致分为两部分:事务管理器本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

①概念:二阶段提交2PCTwo phase Commit是指,在分布式系统里,为了保证所有节点在进行事务提交时保持一致性的一种算法。

②背景:在分布式系统里,每个节点都可以知晓自己操作的成功或者失败,却无法知道其他节点操作的成功或失败。

当一个事务跨多个节点时,为了保持事务的原子性与一致性,需要引入一个协调者Coordinator来统一掌控所有参与者Participant的操作结果,并指示它们是否要把操作结果进行真正的提交(commit)或者回滚(rollback)。

③思路:2PC顾名思义分为两个阶段,其实施思路可概括为:

(1)投票阶段(voting phase:参与者将操作结果通知协调者;

(2)提交阶段(commit phase:收到参与者的通知后,协调者再向参与者发出通知,根据反馈情况决定各参与者是否要提交还是回滚;

④缺陷:算法执行过程中,所有节点都处于阻塞状态,所有节点所持有的资源(例如数据库数据,本地文件等)都处于封锁状态。

2. 代码补偿事务(TCC)

TCC的作用主要是解决跨服务调用场景下的分布式事务问题

①业务场景举例

操作方法

含义

Try

完成所有业务检查(一致性),预留业务资源(准隔离性) 回顾上面航班预定案例的阶段1,机票就是业务资源,所有的资源提供者(航空公司)预留都成功,try阶段才算成功

Confirm

确认执行业务操作,不做任何业务检查, 只使用Try阶段预留的业务资源。回顾上面航班预定案例的阶段2,美团APP确认两个航空公司机票都预留成功,因此向两个航空公司分别发送确认购买的请求。

Cancel

取消Try阶段预留的业务资源。回顾上面航班预定案例的阶段2,如果某个业务方的业务资源没有预留成功,则取消所有业务资源预留请求。

②TCC两阶段提交与XA两阶段提交的区别

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

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

c.其核心在于将业务分为两个操作步骤完成。不依赖 RM 对分布式事务的支持,而是通过对业务逻辑的分解来实现分布式事务。

3.本地消息表(异步确保)- 事务最终一致性

本地消息表这种方案实现了最终一致性,需要在业务系统里增加消息表,业务逻辑中多一次插入的 DB 操作,所以性能会有损耗,而且最终一致性的间隔主要由定时任务的间隔时间决定。

②优点: 一种非常经典的实现,避免了分布式事务,实现了最终一致性。

③缺点: 消息表会耦合到业务系统中,如果没有封装好的解决方案,会有很多杂活需要处理。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值