1.分布式事务简介

本文探讨了分布式事务处理的主流框架,如jta+Atomikos、基于消息队列(rabbitmq、rocketmq)以及seata等。分布式事务产生的背景涉及到多数据源和跨项目操作,导致事务管理复杂。文章还深入讲解了ACID理论、CAP理论和BASE理论,以及强一致性和弱一致性。二阶段提交和三阶段提交协议作为重要的分布式事务协调机制也被提及。

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

1.主流解决分布式事务框架

1)单项目多数据源,jta+Atomikos

2)基于rabbitmq

3)基于rocketmq

4)LCN采用lcn模式(目前已经淘汰)tcc/txc/lcn 3种模式

5)基于seata

2.分布式事务产生背景

项目

数据源

事务管理器

是否产生分布式事务问题

备注

单项目

一个数据源

相同

因为有事务的传播行为

单项目

多个数据源

不相同

jta+Atomikos

多项目

多个数据源

不相同

seata/lcn

注意:不同的数据源(不同的事务管理器)或者不同的项目(不同的JVM)会产生分布式事务的问题

如:订单系统下单和派单,在分布式项目的情况下,调用下单服务成功,调用派单失败,在没有分布式事务的情况下会产生脏数据

3.ACID理论、BASE理论、CAP理论

ACID理论

原子性

一个事务中的所有操作,要么全部成功、要么全部失败

一致性

事务前后数据的完整性必须保持一致

隔离性

多个事务之间互不影响

持久性

事务结束后,对数据的修改是永久的

CAP理论

一致性

故障后保证各地方备份数据保证一致

可用性

故障后保证可用性

分区容错性

分区后产生的网络通讯故障

总结:

CAP无法三者兼顾、要么cp要么ap

CP:网络通讯故障后保证数据一致性、不保证可用性。如zk

AP:网络通讯故障后保证可用性、不保证数据一致性。如eureka

BASE理论

基本可用

分布式系统出现故障后,允许损失部分可用性,但要保证核心可用

软状态

允许系统存在中间状态,但是中间状态不会影响系统整体可用性

最终一致性

允许短暂延迟、但是最终结果必须一致

4.强一致性和弱一致性

强一致性

弱一致性

不会出现脏读

可能会出现脏读

注意:分布式系统无法保证强一致性,允许短暂延迟、但是最终结果必须一致

脏读:一个现在正在修改、一个线程正在读取。修改线程还没提交事务的情况下可能会存在脏读

5.二阶段提交协议和三阶段提交协议

二阶段提交协议

第一阶段:预备阶段

第二阶段:同步阶段

三阶段提交协议

第一阶段:预备阶段

第二阶段:询问阶段

第三阶段:同步阶段

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值