分布式事务

本文介绍分布式事务解决方案,重点阐述两阶段提交协议,包括请求和提交阶段,指出其存在单点故障、同步阻塞、数据不一致等缺点,且无法解决协调者与参与者同时出错时事务执行完整性问题。还提及三阶段提交协议,它在二阶段基础上增加超时和预提交机制。

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

分布式事务解决方案:

两阶段提交协议:

基于XA协议的,采用强一致性,遵从ACID

2PC:(2阶段提交协议),是基于XA/JTA规范

过程:

1.请求阶段(commit-request phase,或称表决阶段,voting phase)

在请求阶段,协调者将通知事务参与者提交或取消事务,然后进入表决过程。

在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。

2.提交阶段:

在该阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消。

当且仅当所有的参与者同意提交事务,协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务。

参与者在接收到协调者发来的消息后将执行响应的操作。

缺点:

单点故障:事务的发起、提交还是取消,均是由老大协调者管理的,只要协调者宕机,那就凉凉了。

同步阻塞缺点:从上面介绍以及例子可以看出,我们的参与系统中在没收到老大的真正提交还是取消事务指令的时候,就是锁定当前的资源,并不真正的做些事务相关操作,所以,整个分布式系统环境就是阻塞的。

数据不一致缺点:就是说在老大协调者向小弟们发送真正提交事务的时候,部分网络故障,造成部分系统没收到真正的指令,那么就会出现部分没提交,因此,这就会导致数据的不一致。

无法解决的问题:

当协调者出错,同时参与者也出错时,两阶段无法保证事务执行的完整性。

考虑协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者也宕机了。那么即使有了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。知道的人已经灭口了。

三阶段提交协议:

采取强一致性,遵从ACID。

在二阶段上增加了:超时和预提交机制。

有着三个主阶段。canCommit、preCommit、doCommit这三个阶段

 

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值