分布式事务seata,TCC,最大努力通知,最终一致性解决方案——总结三!
在介绍各种分布式事务的解决方案后,我们了解到各种方案的优缺点:
在前面两篇文章中,已经介绍了各种解决方案的具体细节。
java分布式事务——seata,tcc解决方案总结!
java分布式事务——最终一致性,最大努力通知总结!
本文咱们就来对各种方案的优缺点做个总结:
2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定,此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高, 因此,这种设计不能适应随着事务涉及的服务数量增加而扩展的需要,很难用于并发较高以及子事务生命周期较长 (long-running transactions) 的分布式服务中。
如果拿TCC事务的处理流程与2PC两阶段提交做比较,2PC通常都是在跨库的DB层面,而TCC则在应用层面的处理,需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于,可以让应用自己定义数据操作的粒度,使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强,业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外,其实现难度也比较大,需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景:满,登录送优惠券等。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后,同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响,并实现了两个服务的解耦。典型的使用场景:注册送积分,登录送优惠券等。
最大努力通知是分布式事务中要求最低的一种,适用于一些最终一致性时间敏感度低的业务;允许发起通知方处理业务失败,在接收通知方收到通知后积极进行失败处理,无论发起通知方如何处理结果都会不影响到接收通知方的后续处理;发起通知方需提供查询执行情况接口,用于接收通知方校对结果。典型的使用场景:银行通知、支付结果通知等。
总结:
在条件允许的情况下,我们尽可能选择本地事务单数据源,因为它减少了网络交互带来的性能损耗,且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务,应首先从整体设计角度观察服务的拆分是否合理,是否高内聚低耦合?是否粒度太小?分布式事务一直是业界难题,因为网络的不确定性,而且我们习惯于拿分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层TCC、可靠消息、最大努力通知等方案,都没有完美解决分布式事务问题,它们不过是各自在性能、一致性、可用性等方面做取舍,寻求某些场景偏好下的权衡。
相关文章
- RabbitMQ学习笔记(七)——RabbitMQ分布式事务框架
- 在 SAP Fiori Gateway 系统配置一个指向 SAPGUI 事务的 tile
- 分布式事务解决方案模型
- 微服务(十六)——Seata 分布式事务框架
- saga分布式事务_spring分布式事务实现
- SpringCloud AlibabaSeata处理分布式事务
- MySQL事务隔离级别
- 分布式事务的案例分析
- 分布式事务如何解决?
- java分布式事务——最终一致性,最大努力通知总结!
- 分布式事务
- Seata分布式事务落地解决方案
- 本地事务和分布式事务
- PostgreSQL数据库事务实现方法分析
- Redis的事务功能详解大数据
- 什么是事务、事务特性、事务隔离级别、spring事务传播特性详解编程语言
- Oracle事务提交:保持数据完整性(Oracle事物提交)
- Java Connection.rollback()方法:事务回滚
- 事务SQL Server实现分布式事务处理(sqlserver分布式)
- 轻松搭建xa环境,用sqlserver实现分布式事务(xa sqlserver)
- MySQL中C语言实现事务执行(c 事务执行mysql)
- 使用Redis解决分布式事务问题(分布式事务用redis)
- 如何避免Oracle事务未关闭带来的问题(oracle事务没有关闭)
- Oracle事务处理探讨其五种类别(oracle事务有哪几类)
- Oracle事务处理的正确结束方式(oracle事务如何结束)
- Redis集群实现高效的事务处理(redis集群事务6)