分布式事务(二)常见解决方案-全局事务

介绍

全局事务基于DTP模型实现。DTP时由X/Open组织提出的一种分布式事务模型,它规定实现分布式事务需要三种角色;

  • AP:Application应用
  • TM:Transaction Manager 事务管理器
  • RM:ResoureManager 资源管理器

两个阶段

全局事务将整个事务拆分成了两个阶段

阶段一 :表决阶段,所有事务参与者都将本事务执行预提交,并将能否提交成功的消息反馈给事务协调者。

阶段二 :执行阶段,事务协调者根据所有参与的反馈,通知所有事务的参与者,全局统一的提交或者回滚。

全局事务案例

继续采用上文的订单商品案例,如图中所示,每个微服务在全局事务中代表AP的角色,各个数据库代表RM角色。

订单微服务生成订单时会先执行预提交,然后将预提交结果反馈给TM;同样商品微服务在扣减库存时也是先执行预扣减,将预扣减结果反馈给TM;TM会根据各个预提交的结果来决定,如果所有的预提交都成功,那么就通知各个事务参与者将事务正式提交,若有一个预提交结果是失败的,那么就会通知各个事务参与者将所有操作回滚。

up-3759311aacd64c227520c1cb1b3a2fe95d9.png

那么,这里会存在一个问题,如果在第二阶段执行时,其中一个事务参与者发生了异常,事务如果保证一致性呢?

其实全局事务的概念并不能完全解决分布式事务问题,它无法感知到第二阶段提交时的情况,有可能会出现数据不一致的情况。它通过第一阶段的预提交表决,可以大大降低异常的概率,不能从根本上解决分布式事务。

优缺点分析

优点:

  • 实现成功低的同时大大降低分布式事务异常的概率

缺点:

  • 事务协调者TM单机运行,可能出现单点故障
  • 延长了事务提交的时间,增加资源占用
  • 感知不到第二阶段提交的异常,无法从根本上解决分步事务

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值