分布式事务专题总结

概述

重点知识

事务的基本概念以及本地事务特性。
CAP、BASE理论的概念。
2PC、TCC、可靠消息最终一致性、最大努力通知个类型原理及特性。
MQ事务消息机制。
Seata与传统XA原理上的差异。

不同分布式事务类型的应用场景

2PC、TCC场景:及时一致性,要求发起方和接收方处理的原子性,要么都处理要么都不处理,这是本地事务的分布式翻版。
可靠消息最终一致性:过程一致性,要求发起方一定发送消息成功、接收方一定处理消息,不要求发起方发送消息后接收方一定立即处理。
最大努力通知:结果一致性,可靠性由接收方保证,发送方尽最大努力通知发起方,不保证一定通知成功,接收方可以调用发起方的校对接口主动查询结果。

分布式事务对比分析

在学习了各种分布式事务的解决方案后,我们了解到各种方案的优缺点:

2PC

2PC最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定,此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高,因此,这种设计不能适应随着事务设计的服务数量增加而扩展需求,很难用于并发较高以及子事务生命周期较长的分布式事务中。

TCC

如果拿TCC事务的处理流程与2PC两阶段提交做比较,2PC通常都是在跨库的DB层面,而TCC则在应用层面的处理,需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于,可以让应用自己定义数据操作的粒度,使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强,业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外,其实现难度也比较大,需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景:满减、登录送优惠券等。

可靠消息最终一致性

可靠性最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后,同步的事务操作变为基于消息执行的异步操作,避免了分布式事务中的同步阻塞操作的影响,并实现了两个服务的解耦。典型的使用场景:注册送积分,登录送优惠券等。

最大努力通知

最大努力通知是分布式事务中要求最低的一种,适用于一些最终一致性时间敏感度低的业务;允许发起通知方处理业务失败,在接收通知方收到通知后积极进行失败处理,无论发起通知方如何处理结果都不会影响到接收通知方的后续处理;发起通知方需要提供查询执行情况接口,用于接收通知方校对结果。电影的使用场景:银行通知、支付结果通知等。
在这里插入图片描述

总结

在条件允许的情况下,我们尽可能选择本地事务单数据源,因为它减少了网络交互带来的性能损耗,且避免了数据弱一致性带来的种种问题。若某系统频发且不合理的使用分布式事务,因首先从整体设计角度观察服务的拆分是否合理,是否高内聚低耦合?是否粒度太小?分布式事务一直是业界难题,因为网络的不确定性,而且我们习惯于拿分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层的TCC、可靠消息、最大努力通知等方案,都没有完美解决分布式事务问题,它们不过是各自在性能、一致性、可用性等方面做取舍,寻求某些场景偏好下的权衡。

参考

看了 5 种分布式事务方案,我司最终选择了 Seata,真香!

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

融极

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值