分布式事务概述

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

CAP定理

· C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

· A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的。

· P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

CAP定理无法同时满足三者。

seata概述

Seata是一款分布式事务解决方案，它提供了一种高可用、高性能、易于使用的分布式事务解决方案。Seata解决了在分布式环境下的事务一致性问题，使得分布式环境下的事务处理更加简单、可靠和高效。

Seata提供了一整套的分布式事务解决方案，包括全局事务ID的生成和管理、分支事务的注册和协调、以及事务的恢复和回滚等功能。它支持多种事务模式，如AT模式、TCC模式和Saga模式，能够与各种主流的分布式系统和框架集成，如Spring Cloud、Dubbo、MyBatis等。

在Seata中，每个全局事务由一个全局事务ID（Global Transaction ID）唯一标识，它负责协调和管理所有的分支事务。在分支事务执行期间，Seata会将每个分支事务注册到全局事务中，以保证所有的分支事务都能够得到正确的协调和管理。如果有分支事务出现异常，Seata将会启动事务回滚机制，保证所有的分支事务都能够回滚到正确的状态。

在AT模式下，Seata使用类似于传统数据库事务的两阶段提交协议（2PC），实现了分布式事务的一致性。在TCC模式下，Seata使用尝试/确认/取消的机制，实现了更加灵活的事务处理方式。在Saga模式下，Seata支持长事务处理，通过不断的补偿操作来保证事务的最终一致性。

Seata 的定位是分布式事全场景解决方案，未来还会有 XA 模式的分布式事务实现，每种模式都有它的适用场景，AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。

seata核心组件

事务： 一个程序执行单元，是用户定义的一组操作序列，需要满足ACID属性。

本地事务：事务由本地资源管理器管理。

分布式事务：事务的操作位于不同的节点。

分支事务：在分布式事务中，由资源管理器管理的本地事务。

全局事务：一次性操作多个资源管理器完成的事务，由一组分支事务组成。

三大组件

Transaction Coordinator(TC): 全局事务协调者，用来协调全局事务和各个分支事务（不同服务）的状态，驱动全局事务和各个分支事务的回滚或提交。

Transaction Manager（TM）: 事务管理者，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）。

Resource Manager(RM): 资源管理者，一般指业务数据库代表了一个分支事务（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚。

Seata 实现分布式事务，设计了一个关键角色 UNDO_LOG （回滚日志记录表），我们在每个应用分布式事务的业务库中创建这张表，这个表的核心作用就是，将业务数据在更新前后的数据镜像组织成回滚日志，备份在 UNDO_LOG 表中，以便业务异常能随时回滚。

基础交互

TC是需要独立部署的服务，TM和RM是集成在服务中，三大组件相互协作，共同完成分布事务的管理；

执行流程

在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态）；
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
TC 汇总事务信息，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚资源，事务二阶段结束；

回滚机制

Seata中，回滚机制的实现主要包括以下几个方面：

实现本地事务的回滚。在Seata中，每个参与者都需要实现本地事务，当事务出现异常或者错误时，需要回滚本地事务，以保证数据的一致性。本地事务的回滚可以通过Seata提供的UndoLog机制来实现。
实现全局事务的回滚。当分支事务中的任何一个事务发生异常或者错误时，全局事务也需要回滚，以保证数据的一致性。在Seata中，全局事务的回滚可以通过全局事务协调器来实现，协调器负责收集分支事务的状态，并根据分支事务的状态判断是否需要回滚全局事务。
处理事务回滚异常。在Seata中，回滚也可能会发生异常，例如网络异常、故障等情况。为了保证分布式事务的可靠性和容错性，Seata提供了重试和补偿机制，以处理事务回滚异常。

机制详解：

UndoLog机制：在Seata中，每个参与者在执行本地事务时，会生成UndoLog。UndoLog记录了本地事务执行前的数据状态，当事务需要回滚时，可以通过UndoLog将数据恢复到事务执行前的状态。UndoLog的生成和应用是通过Seata提供的拦截器来实现的，拦截器可以拦截方法的执行，并在执行前后生成和应用UndoLog。
全局事务协调器：在Seata中，全局事务的管理和协调是通过全局事务协调器来实现的。当分支事务中的任何一个事务出现异常时，协调器会收集所有分支事务的状态，并根据分支事务的状态判断是否需要回滚全局事务。如果需要回滚全局事务，协调器会向所有参与者发送回滚请求，并等待参与者的回应。如果所有参与者都成功回滚了本地事务，协调器会通知所有参与者回滚全局事务。
重试和补偿机制：在分布式事务中，回滚也可能会发生异常，例如网络异常、故障等情况。为了保证分布式事务的可靠性和容错性，Seata提供了重试和补偿机制，以处理事务回滚异常。如果回滚操作发生异常，Seata会根据预设的重试策略进行重试，如果重试多次仍然失败，Seata会使用补偿机制来处理回滚异常。

rhb_blog

seata（一）——概述