分布式事务大汇总_分布式事务汇总-CSDN博客

本文链接：https://blog.csdn.net/weixin_73077810/article/details/130500140

分布式事务是为了保证在数据库分库分表或应用SOA化后，不同数据库间数据的一致性。其理论基础包括CAP定理和BASE理论。Seata是一个开源的分布式事务解决方案，提供了XA、TCC、AT和SAGA四种模式。其中，XA模式保证强一致性但性能较低，AT模式则通过数据快照实现最终一致性，而TCC和SAGA模式则是通过补偿操作来确保一致性。

摘要由CSDN通过智能技术生成

什么是分布式事务?

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务的产生的原因

数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

分布式事务的理论基础：

CAP + BASE 分布式事务理论基础https://blog.csdn.net/weixin_73077810/article/details/130403217

分布式事务思想

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

AP模式（最终一致性思想）：

各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施（删了重新加回来，加了删回去...）恢复数据即可，实现最终一致。

CP模式（强一致性思想）：

各个子事务执行后互相等待，先不提交事务，直到所有的事务都执行后，确认没问题了，就同时提交，有问题就同时回滚，达成强一致。但事务等待过程中，处于业务弱可用状态（阻塞不可用状态）。

分布式事务解决方案

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

Seata官网http://seata.io/zh-cn/

Seata架构

Seata提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入

TCC模式：最终一致的分阶段事务模式，有业务侵入

AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

SAGA模式：长事务模式，有业务侵入

Seata的四大模式

XA 模式

X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

正常的进行：

如果进行异常：

综上所述，XA规范是基于数据库本身的特性（提交 / 回滚）来进行的，所以说它是满足ACID四大事务特性的强一致性事务

XA模式的优点是什么？

        事务的强一致性，满足ACID原则。

        常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

        因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差

        依赖关系型数据库实现事务

AT 模式

简述AT模式与XA模式最大的区别是什么？

        XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

        XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

        XA模式强一致；AT模式最终一致

AT脏写场景——多线程并发

由于事务的隔离性问题，所以说一个线程的第一第二阶段可能被隔离为两个不相邻的时间段执行，这样子就导致数据的不一致性，解决办法就是将一个事务的第一第二阶段的执行都进行一个上锁操作，确保第一第二阶段的操作满足原子性

但是要注意的是，上述的全局锁只对SeaTa进行管理的事务生效，所以说，当你一个Seata事务在进行的过程中，一个非seata管理的事务是可以不受全局锁的限制进行CRUD的，这样就体现了AT模式区别与XA模式的一种低隔离性状态，但是这种情况也可能会造成数据安全问题，所以说，Seata采用以下办法进行解决

由上可见，Seata的快照是拍摄两份的，一份在业务执行前拍摄（用于分布式事务失败后的回滚），一份在业务执行后拍摄（用于判断极端情况下的非Seata管理的事务对Seata还礼的事务的影响），在Seata发现事务异常的时候不是直接通过before-image进行恢复，而是先比较一下当前数据和after-image，如果一致就通过before-image进行恢复，反之就得上人工解决

TCC模式

详情查看以往我写过的一篇对于TCC的讲解文章https://blog.csdn.net/weixin_73077810/article/details/130499441

Saga模式

Saga模式是“Saga Pattern”（即“长事务模式”）的缩写，它将分布式事务分为一系列连续的局部事务，并在每个局部事务中将事务状态作为事件广播给其他参与者，从而保证各局部事务的一致性。在这种模式下，每个参与者都需要根据接收到的事件决定是否执行某个局部事务。如果接收到的事件需要执行局部事务，则该参与者会进行操作；如果接收到的事件需要撤消局部事务，则该参与者会进行回滚操作。通过这种方式，Saga模式能够在各参与者之间建立高度解耦的通信机制，确保整个分布式事务的一致性。