当前位置：首页 > news >正文

分布式事务与Seata

news 来源：原创 2025/4/30 4:35:05

什么是分布式事务：

分布式事务是指在分布式系统中，跨多个节点（服务、数据库、消息队列等）的事务操作。它需要保证这些操作要么全部成功，要么全部失败，以满足事务的 ACID 特性（原子性、一致性、隔离性、持久性）。由于分布式系统的复杂性（如网络延迟、分区、节点故障等），实现分布式事务比单机事务更具挑战性。

分布式的相关概念：

1. 强一致性（Strong Consistency）

定义：在分布式系统中，任何时刻读取的数据都是最新的，所有节点看到的数据是一致的。
特点：
- 保证数据的实时一致性。
- 通常通过锁或同步机制实现，但会牺牲性能。
例子：2PC（两阶段提交）是实现强一致性的典型方法。

2. 最终一致性（Eventual Consistency）

定义：在分布式系统中，数据经过一段时间后最终达到一致状态，但在某一时刻可能不一致。
特点：
- 允许短暂的数据不一致，但最终会一致。
- 适合对一致性要求不高的场景，性能较好。
例子：Saga、MQ事务消息、最大努力通知等方法通常实现最终一致性。

3. CAP定理

定义：在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance） 三者不可兼得，最多只能同时满足其中两项。
- 一致性（C）：所有节点看到的数据是一致的。
- 可用性（A）：每个请求都能得到响应。
- 分区容错性（P）：系统在网络分区的情况下仍能正常运行。
意义：分布式系统设计时需要根据业务需求权衡 CAP 特性。

4. BASE理论

定义：BASE 是对 CAP 中一致性和可用性权衡的延伸，包含以下三个特性：
- Basically Available（基本可用）：系统在出现故障时仍能提供基本功能。
- Soft state（软状态）：系统中的数据可以存在中间状态，允许短暂的不一致。
- Eventually consistent（最终一致性）：数据最终会达到一致状态。
意义：BASE 理论是最终一致性的理论基础，适合高可用和高性能的场景。

5. 分布式事务的实现模式

2PC（两阶段提交）：
- 分为准备阶段和提交阶段，协调者负责协调参与者的事务提交。
- 优点：强一致性。
- 缺点：性能低，存在单点故障。
3PC（三阶段提交）：
- 在2PC的基础上增加了预提交阶段，减少阻塞时间。
- 优点：性能优于2PC。
- 缺点：实现复杂，仍可能不一致。
TCC（Try-Confirm-Cancel）：
- 通过业务逻辑实现事务补偿，分为尝试、确认、取消三个阶段。
- 优点：高性能，适合高并发。
- 缺点：实现复杂，业务侵入性强。
Saga：
- 将长事务拆分为多个本地事务，通过补偿机制保证最终一致性。
- 优点：适合长事务，性能好。
- 缺点：数据一致性较弱。
本地事务表：
- 通过本地事务记录分布式事务状态，异步同步数据。
- 优点：实现简单。
- 缺点：扩展性差。
MQ事务消息：
- 通过消息队列实现事务的异步提交。
- 优点：性能高。
- 缺点：消息可能丢失或重复。
最大努力通知：
- 通过重试机制保证事务最终完成。
- 优点：实现简单。
- 缺点：数据一致性无法保证。

6. 分布式锁

定义：在分布式系统中，用于控制多个节点对共享资源的访问。
实现方式：Redis分布式锁、Zookeeper分布式锁等。
特点：保证资源的互斥访问，但可能引入性能瓶颈。

7. 分布式一致性算法

Paxos：一种分布式一致性算法，用于解决分布式系统中的一致性问题。
Raft：Paxos的简化版本，易于理解和实现，常用于分布式系统的领导者选举和数据同步。

8. 分布式ID生成

定义：在分布式系统中生成全局唯一的ID。
实现方式：雪花算法（Snowflake）、UUID、数据库自增ID等。
特点：需要保证ID的唯一性和高性能。

9. 分布式缓存

定义：在分布式系统中，将数据缓存到多个节点以提高访问速度。
实现方式：Redis集群、Memcached等。
特点：提高系统性能，但需要解决缓存一致性问题。

10. 分布式文件系统

定义：将文件存储分布到多个节点上，提供高可用性和扩展性。
例子：HDFS（Hadoop分布式文件系统）、Ceph等。

11. 分布式计算

定义：将计算任务分布到多个节点上并行处理。
例子：MapReduce、Spark等。

12. 分布式追踪

定义：在分布式系统中追踪请求的调用链路，用于性能分析和故障排查。
例子：Zipkin、SkyWalking等。

分布式事务的优缺点：

方法	优点	缺点
2PC（两阶段提交）	1. 强一致性。 2. 实现简单，适合数据库层面的事务协调。	1. 同步阻塞，性能较低。 2. 单点故障问题。 3. 数据不一致时难以恢复。
3PC（三阶段提交）	1. 减少阻塞时间，性能优于2PC。 2. 解决了2PC的部分单点故障问题。	1. 实现复杂。 2. 仍然存在数据不一致的风险。 3. 网络分区问题未完全解决。
TCC（Try-Confirm-Cancel）	1. 高性能，适合高并发场景。 2. 灵活性高，可自定义业务逻辑。	1. 实现复杂，需编写大量补偿逻辑。 2. 业务侵入性强。
Saga	1. 适合长事务。 2. 异步执行，性能较好。 3. 无全局锁，扩展性强。	1. 数据一致性较弱（最终一致性）。 2. 补偿逻辑复杂。
本地事务表	1. 实现简单。 2. 适合小规模分布式系统。	1. 数据一致性依赖本地事务。 2. 扩展性差，不适合大规模系统。
MQ事务消息	1. 异步处理，性能高。 2. 适合消息驱动的场景。	1. 消息可能丢失或重复。 2. 数据一致性依赖消息队列的可靠性。
最大努力通知	1. 实现简单。 2. 适合对一致性要求不高的场景。	1. 数据一致性无法保证。 2. 依赖外部系统的重试机制。

什么是Seata：

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和XA 事务模式，为用户打造一站式的分布式解决方案。AT模式是阿里首推的模式,阿里云上有商用版本的GTS（Global Transaction Service 全局事务服务）。

Seata的三大角色：

TC (Transaction Coordinator) - 事务协调者：
维护全局和分支事务的状态，驱动全局事务提交或回滚。
- TM (Transaction Manager) - 事务管理器：
  定义全局事务的范围：开始全局事务、提交或回滚全局事务。
  - RM (Resource Manager) - 资源管理器：
    管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata 的 AT 模式与分布式事务的关联

Seata 是一款开源的分布式事务解决方案，提供了多种模式来支持分布式事务，其中 AT（Auto Transaction）模式 是 Seata 的核心模式之一。AT 模式与常见的分布式事务方法（如 2PC、TCC、Saga 等）有相似之处，但也有其独特的设计和实现方式。

Seata AT 模式的核心思想

AT 模式是一种 基于本地事务的分布式事务解决方案，它通过对业务代码的 无侵入性 改造，实现了分布式事务的管理。其核心思想是：

全局事务：由 Seata 的事务协调器（TC）管理，负责协调多个分支事务。
分支事务：每个分支事务是一个本地事务，由 Seata 的 RM（资源管理器）管理。
两阶段提交：AT 模式借鉴了 2PC 的思想，但通过 本地事务 和 全局锁 实现了更高的性能。

AT 模式的工作流程

第一阶段（执行阶段）：
- 业务代码执行本地事务，Seata 会拦截 SQL 语句，生成 前置镜像（Before Image） 和 后置镜像（After Image）。
- 本地事务提交后，Seata 将分支事务的状态和镜像数据注册到全局事务中。
第二阶段（提交/回滚阶段）：
- 如果所有分支事务都成功，Seata 会异步清理全局事务的日志。
- 如果有分支事务失败，Seata 会根据镜像数据自动回滚已提交的分支事务。

AT 模式与常见分布式事务方法的对比

方法	实现方式	优点	缺点
Seata AT 模式	基于本地事务，通过拦截 SQL 生成镜像数据，实现自动提交和回滚。	1. 对业务代码无侵入。 2. 性能较高。 3. 支持强一致性。	1. 依赖数据库的本地事务。 2. 需要全局锁，可能影响性能。
2PC（两阶段提交）	通过协调者和参与者实现两阶段提交。	1. 强一致性。 2. 实现简单。	1. 同步阻塞，性能低。 2. 单点故障问题。
TCC（Try-Confirm-Cancel）	通过业务逻辑实现补偿机制，分为 Try、Confirm、Cancel 三个阶段。	1. 高性能。 2. 灵活性高。	1. 实现复杂。 2. 业务侵入性强。
Saga	将长事务拆分为多个本地事务，通过补偿机制保证最终一致性。	1. 适合长事务。 2. 异步执行，性能好。	1. 数据一致性较弱。 2. 补偿逻辑复杂。
MQ事务消息	通过消息队列实现事务的异步提交。	1. 异步处理，性能高。 2. 适合消息驱动的场景。	1. 消息可能丢失或重复。 2. 数据一致性依赖消息队列的可靠性。