七 两阶段事务的问题

两阶段事务-协调者宕机分析

在这里插入图片描述

1.如果在第一阶段,协调者宕机,那么所有参与者将无法再收到协调者第二阶段的commit或rollback命令,故会一直阻塞下去,本地事务无法结束
解决方案∶所有参与者统一rollback(因为还未进入第二阶段,所有参与者都不会接收到提交或回滚的命令,当前事务是无法继续提交的,故只能回滚。)

2.如果在第二阶段,协调者宕机,那么可能部分参与者没有接收到Commit、rollback,那么这部分没有接收到命令的参与者都会一直阻塞下去。

两阶段事务-参与者宕机分析

在这里插入图片描述

1.如果在第一阶段,某个参与者宕机,那么会导致协调者一直等待这个参与者的响应,从而导致其它参与者也进入阻塞,全局事务将无法结束。
解决方案∶所有参与者统一rolback(因为还未进入第二阶段,所有参与者都不会接收到提交或回滚的命令,当前事务是无法继续提交的,故只能回滚。)
2.如果在第二阶段,协调者发起Commit时,某个参与者宕机,已经执行Commit的参与者数据库已经修改成功,但是宕机的参与者就无法Commit,这个时候就会参数数据不一致的问题。

两阶段事务-网络问题(脑裂)

1.网络闪断,发生在第一阶段∶会有部分参与者进入阻塞,全局事务无法结束。
解决方案∶所有参与者统一rolback(因为还未进入第二阶段,所有参与者都不会接收到提交或回滚的命令,当前事务是无法继续提交的,故只能回滚。)
2.网络闪断,发生在第二阶段∶会有部分参与者Commit另一部分参与者未Commit,从而导致数据

思考题∶

当在第二阶段,出现了协调者 或参与者宕机,或网络脑裂;就会出现某个参与者不知道其他参与者究竟是Commit、rollback;
如果参与者采用超时机制,那么超时后重试,是该提交还是回滚?如果是执行回滚,那太保守,如果执行提交,那太激进暴力。如果是你,你会怎么做?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分布式事务阶段提交(Two-Phase Commit,2PC)是一种常见的分布式事务协议,用于协调多个参与者节点的提交或回滚操作。它包括以下阶段: 1. 准备阶段(Prepare Phase):在准备阶段,协调者节点(也称为事务管理器)向所有参与者节点发送准备请求,并等待它们的响应。参与者节点接收到准备请求后,会执行事务的准备操作,检查是否能够成功执行事务。如果参与者节点准备就绪,它会向协调者节点发送“同意”响应,表示可以进行提交操作。如果有任何一个参与者节点无法准备就绪,它会向协调者节点发送“止”响应,表示无法执行事务。 2. 提交阶段(Commit Phase):在提交阶段,如果所有参与者节点都发送了“同意”响应,协调者节点会向所有参与者节点发送提交请求,要求它们执行事务的提交操作。参与者节点接收到提交请求后,会执行事务的提交操作,并向协调者节点发送“完成”响应。如果有任何一个参与者节点无法执行提交操作,它会向协调者节点发送“止”响应。 协调者节点在等待一定时间后,收集所有参与者节点的响应,如果收到了所有参与者节点的“完成”响应,它会向所有参与者节点发送“全局提交”指令,表示事务的提交完成。如果协调者节点收到了任何一个参与者节点的“止”响应或超时,它会向所有参与者节点发送“全局回滚”指令,表示事务的回滚。 阶段提交协议保证了分布式事务的原子性和一致性,但它也存在一些缺点,比如协调者节点的单点故障、阻塞等待参与者节点响应导致性能问题等。因此,在实际应用,还需要考虑其他的分布式事务解决方案来满足具体的业务需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值