分布式事务

分布式事务旨在解决跨服务和跨库操作的一致性问题。它遵循CAP理论,通常选择分区容错和最终一致性。2PC(两阶段提交)作为经典方案,存在单点故障和同步阻塞等缺点。TCC(尝试、确认、补偿)通过预操作避免了2PC的部分问题,但实现复杂。可靠消息最终一致性方案通过本地消息表和RocketMQ事务消息确保数据最终一致,降低了同步成本。

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

分布式事务

一、出现背景

1.场景

跨服务
跨库

2.原理

CAP

强一致、高可用、分区容错
通常分布式系统的各各结点部署在不同的子网,这就是网络分区,不可避免的会出现由于网络问题而导致结点之间通信失败,此时仍可对外提供服务,这叫分区容忍性。

BASE理论

基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。
软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是CAP中的不一致。
最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

二、解决方案

1.2PC(两阶段提交)

什么是2PC

在这里插入图片描述
在这里插入图片描述

具体实现
XA实现

在这里插入图片描述
缺点
单点问题:事务管理器在整个流程中扮演的角色很关键,如果其宕机,比如在第一阶段已经完成,在第二阶段正准备提交的时候事务管理器宕机,资源管理器就会一直阻塞,导致数据库无法使用。

同步阻塞:在准备就绪之后,资源管理器中的资源一直处于阻塞,直到提交完成,释放资源。

数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计,但仍然存在数据不一致性的可能,比如在第二阶段中,假设协调者发出了事务commit的通知,但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作,其余的参与者则因为没有收到通知一直处于阻塞状态,这时候就产生了数据的不一致性。

在这里插入图片描述
在这里插入图片描述

2.TCC

概念

在这里插入图片描述

三种异常

在这里插入图片描述
在这里插入图片描述

优缺点

在这里插入图片描述

3.可靠消息最终一致性

在这里插入图片描述

本地消息表方案

在这里插入图片描述

RocketMQ事务消息方案

在这里插入图片描述
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值