分布式事务

分布式事务问题

在分布式系统中，通常一个业务需要跨越多个数据源去远程调用获取数据，而如果在使用传统的单体事务控制，则只能保证调用者所在的数据库的ACID，而无法满足整体的一致性，此时我们就要引入分布式事务

CAP定理

CAP定理，也被称为Brewer定理，是分布式计算中的一个核心概念，它强调了分布式系统中一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）这三个关键属性之间的固有权衡。这一理论由计算机科学家Eric Brewer在2000年首次提出。

CAP定理的组成

一致性（Consistency）：在分布式系统中，一致性意味着系统中的所有节点在同一时间看到相同的数据。换句话说，当发生写操作时，所有后续的读操作都应反映该写操作。这是分布式系统数据一致性的基本要求。
可用性（Availability）：可用性指的是系统中每个节点对读和写请求的响应能力，即使一些节点经历故障或延迟。一个可用的系统能够确保请求得到响应，但不保证响应中包含最新的写入。
分区容忍性（Partition Tolerance）：分区容忍性涉及系统在发生网络分区（即通信失败）时继续运行和提供服务的能力。它要求系统能够容忍消息的丢失或节点间通信的延迟，以保证系统的整体稳定性和可靠性。

CAP定理的核心观点

CAP定理指出，一个分布式系统最多只能同时实现这三个属性中的两个。这是因为在分布式环境中，网络分区是不可避免的，而在分区发生时，系统需要在一致性和可用性之间做出选择。具体来说：

如果系统选择保证一致性，那么在网络分区期间可能会牺牲可用性，因为系统需要等待所有节点就绪以保证数据一致。
如果系统选择保证可用性，那么在网络分区期间可能会牺牲一致性，因为系统需要允许某些节点响应请求以维持服务。

BASE理论

BASE理论可以看作是CAP定理的一种延伸和补充。CAP定理指出一个分布式系统不可能同时满足一致性、可用性和分区容错性三个属性中的全部，而BASE理论则通过放宽一致性的要求来实现在分区容错性和可用性之间的平衡。因此，在设计分布式系统时，可以根据具体需求选择合适的策略来平衡这三个属性之间的关系。

三个思想

基本可用（Basically Available）

定义：系统保证在出现故障或者数据损坏的情况下，依然能够保持核心功能的可用性，并且尽可能地提供其他功能的可用性。这意味着系统应该尽量避免完全不可用的情况，即使部分功能或性能受损，也应保证基本的响应能力。
应用场景：在电商网站的高峰期，为了保证系统的整体可用性，可能会采用降级页面或延迟响应等方式，允许部分请求得到响应，但可能牺牲部分实时性或数据一致性。

软状态（Soft State）

定义：系统中的数据可以没有时效性，即数据不需要一直保持一致，可以存在一段时间的不一致状态。这种状态是暂时的，系统会通过后续的处理来逐渐将数据状态调整为一致。
特点：软状态允许系统在不同节点的数据副本之间进行数据同步的过程存在延时，这种延时不会影响系统的整体可用性。
应用场景：在分布式缓存系统中，可能会采用异步复制的方式来进行数据同步，以提高响应速度和吞吐量。这种异步复制方式就体现了软状态的特点。

最终一致性（Eventually Consistent）

定义：系统不需要保证在每个节点上的数据都是实时一致的，但是系统会确保所有节点上的数据在经过一定时间的同步后最终达到一致状态。这是一种弱一致性模型，它允许系统在某些时刻不满足强一致性要求，但保证最终数据会一致。
应用场景：在社交媒体平台中，用户需要实时地与其他用户进行互动，并获取最新的信息更新。为了提高性能，平台可以采用缓存技术和分布式数据存储，以加速数据访问和查询。在一致性方面，可以采用最终一致性的策略，即用户可以看到稍有延迟的最新数据，而不需要立即保证所有数据副本的一致性。

分布式事务模型

解决分布式事务，各个子系统之间必须能感知彼此的事务状态，才能保持状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。这里的子系统事务称为分支事务，有关联的各个分支事务在一起称为全局事务。

Seata

Seata是一款开源的分布式事务解决方案，由阿里巴巴发起并维护，致力于提供高性能和简单易用的分布式事务服务。它支持多种分布式事务模式，包括AT（原子性事务）、TCC（尝试、确认、取消）、Saga（有限状态机）和XA（两阶段提交）等，为用户打造一站式的分布式解决方案。以下是关于Seata的详细介绍：

三个重要角色

TC（Transaction Coordinator）- 事务协调者：
- 职责：维护全局和分支事务的状态，协调全局事务的提交或回滚。它是事务管理的核心，负责接收来自事务管理器（TM）的请求，并根据这些请求来驱动资源管理器（RM）执行相应的操作。
- 特点：TC是一个独立的微服务，通常作为单独部署的Server服务端运行，不包含任何业务代码，仅负责事务的协调工作。
TM（Transaction Manager）- 事务管理器：
- 职责：定义全局事务的范围，开始全局事务，提交或回滚全局事务。它是分布式事务的入口，负责在业务逻辑开始时开启一个全局事务，并在业务逻辑结束时根据执行结果来决定是提交还是回滚这个全局事务。
- 特点：TM通常被嵌入到应用中的Client客户端，通过拦截业务方法的执行来监控全局事务的范围。它会与TC进行交互，以注册全局事务、报告事务状态等。
RM（Resource Manager）- 资源管理器：
- 职责：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。它是事务的参与者，负责执行具体的分支事务操作，如数据库操作、服务调用等。
- 特点：RM同样被嵌入到应用中的Client客户端，与TM一起协作完成全局事务的执行。它会在TC的协调下，执行本地事务的提交或回滚操作，以确保全局事务的一致性。

Seata工作模式

1.XA模式

简介：基于数据库的XA协议来实现两阶段提交（2PC）。
工作原理：通过XA协议来管理分布式事务，确保全局事务的一致性和完整性。
适用场景：适用于强一致性的场景，如金融、银行等。
工作流程：由TM通知TC开启全局事务，TM调用其中的每一个RM，RM开始将自己注册到TC中，并开始执行自己的业务sql，在执行过后向TC报告事务状态，在所有RM执行完后，由TM通知TC要开始决策是提交还是回滚事务，TC根据刚才每一个RM报告的事务状态通知每一个RM是执行提交还是回滚
优点：事务的强一致性，满足ACID原则，常用数据库都支持，实现简单，没有代码侵入
缺点：TC需要等待每一个RM将状态报告完毕，才能进行决定提交或回滚，这是同步的，性能较差，依赖关系型数据库实现事务

2.AT模式（默认模式）

简介：提供无侵入自动补偿的事务模式，目前已支持MySQL、Oracle、PostgreSQL、TiDB和MariaDB等数据库。
工作原理：通过协调各个分支事务的执行状态，确保分布式事务的一致性。如果发生异常，Seata能够协调回滚所有相关分支事务，保持数据的一致性。
适用场景：适用于需要强一致性的分布式事务场景。
工作流程：由TM通知TC开启全局事务，TM调用其中的每一个RM，RM开始将自己注册到TC中，并开始执行自己的业务sql并提交，记录更新前后的快照，向TC报告事务状态，待所有RM执行完后，TM通知TC提交或回滚全局事务，TC根据RM报告的状态是否一致，若全部成功，则通知RM删除快照数据，若有一个失败，则根据之前的快照数据进行回复并删除快照数据
与XA区别：XA模式第一阶段不提交事务，锁定资源，AT模式一阶段直接提交事务，不锁定资源。XA模式依赖数据库机制实现回滚，AT模式利用数据快照实现数据回滚。XA模式强一致，AT模式最终一致
优点：一阶段直接提交事务，释放数据库资源，性能比较好，利用全局锁实现读写隔离，没有代码侵入，框架自动完成回滚和提交
缺点：两阶段中间属于软状态，属于最终一致，框架的快照功能会影响性能，但比XA模式要好很多

3.TCC模式

简介：Try Confirm/Cancel，即尝试、确认、取消模式。
工作原理：首先执行Try操作，用于尝试执行分支事务；如果所有分支事务的Try操作都成功，则执行Confirm操作，用于确认并提交已经执行的分支事务；如果任何分支事务的Try操作失败，或者在Confirm操作期间发生了异常，则执行Cancel操作，用于回滚已经执行的分支事务。
适用场景：对业务代码侵入性较强，必要时可能还要修改数据库，适用于需要高度灵活控制事务流程的场景。
工作流程：整体的工作流程与AT模式较为相似，TCC模式通过编程的方式实现事务控制逻辑，需要开发者在业务代码中显式地编写Try、Confirm和Cancel三个阶段的逻辑。Try阶段用于执行业务逻辑并预留必要的资源，Confirm阶段用于在Try阶段成功后实际提交事务，Cancel阶段则用于在Try或Confirm失败时回滚预留的资源。
优点：一阶段直接提交事务，释放数据库资源，性能好，相比AT模型，无需生成快照，无需使用全局锁，性能最强。不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
缺点：有代码侵入，需要认为编写try,confirm,cancel接口，太麻烦。软状态，事务时最终一致。需要考虑confirm和cancel的失败情况，做好幂等处理

4.Saga模式

简介：长事务解决方案，基于状态机来实现。
工作原理：业务流程中每个参与者都提交本地事务，当出现某一个参与者失败时，则补偿前面已经成功的参与者。一阶段正向服务和二阶段补偿服务都由业务开发实现。
适用场景：业务流程长、业务流程多，参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口。
工作流程：第一阶段直接提交本地事务，的第二阶段成功则什么也不做，失败则通过补偿业务来回滚
优点：事务参与者可以基于事件驱动实现异步调用，吞吐高。一阶段直接提交事务，无锁性能好。不用编写TCC的三个阶段，实现简单
缺点：软状态持续时间不确定，时效性差。没有锁，没有事务隔离，会有脏写

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	弱一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性，隔离性有高要求的业务场景	基于关系型数据库的大部分分布式事务场景都可以	对性能有较高要求，有非关系型数据库要参与的事务	业务流程长多，参与者包含其他公司或遗留的系统服务，无法提供TCC模式要求的三个接口