分布式事务是分布式系统开发中的一大挑战，XA 协议作为经典的强一致性解决方案，基于 **两阶段提交（2PC）** 协议来保证所有事务参与者要么全部成功，要么全部失败。本文将深入剖析 XA 协议的原理，并通过 Seata 框架实现 XA 模式的实际应用。

## 分布式事务与 XA 协议

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统节点上。XA是由X/Open组织提出的分布式事务处理（DTP，Distributed Transaction Processing）规范，旨在保证分布式事务的强一致性（ACID原则），几乎所有主流数据库（如MySQL、Oracle等）都对XA规范提供了支持。

XA协议通过 **两阶段提交（2PC） 机制**，协调多个 **资源管理器（RM）**，确保在分布式事务中，所有参与者要么全部提交，要么全部回滚。

在DTP模型中，核心组件包括：

* **应用程序（AP）**：定义事务边界（即事务的开始和结束），并在事务边界内对资源进行操作。
* **事务管理器（TM）**：负责分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。在Seata中，TM通常指开启了全局事务的业务程序。
* **资源管理器（RM）**：如数据库、文件系统等，并提供访问资源的方式。在Seata中，RM指参与分布式事务的每个微服务。

## XA协议原理剖析：两阶段提交（2PC）

XA 协议的核心是两阶段提交（2PC），其基本思想是将事务的提交过程分为两个阶段来执行。

### 阶段一：准备阶段

准备阶段的主要目的是 **确认所有事务参与者是否都准备好提交事务**，具体步骤如下：

1. 协调者询问：事务协调者（TM）向所有参与者（RM）发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2. 参与者执行：各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3. 参与者反馈：如果参与者执行成功，给协调者反馈Yes（可以提交）；如果执行失败，则反馈No（不可提交）。

### 阶段二：提交阶段

提交阶段的主要目的是根据 **准备阶段的反馈结果，决定是真正提交事务还是回滚事务**：

#### 场景一：所有参与者均反馈Yes

协调者提交请求：协调者向所有参与者发出正式提交事务的请求（即Commit请求）。

1. 参与者提交：参与者执行Commit请求，并释放整个事务期间占用的资源。
2. 参与者确认：各参与者向协调者反馈Ack（应答）完成的消息。
3. 完成事务：协调者收到所有参与者反馈的Ack消息后，完成事务提交。

#### 场景二：任何参与者反馈No或超时

1. 协调者回滚请求：协调者向所有参与者发出回滚请求（即Rollback请求）。
2. 参与者回滚：参与者使用阶段一中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3. 参与者确认：各参与者向协调者反馈Ack完成的消息。
4. 完成中断：协调者收到所有参与者反馈的Ack消息后，完成事务中断。

### 2PC的优缺点

**优点：**

* 强一致性：满足ACID原则，是分布式事务强一致性的经典解决方案。
* 简单易懂：方案实现起来相对简单，主要数据库都支持，对业务侵入低。

**缺点：**

* 同步阻塞问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
* 单点故障问题：如果协调者（TM）出现故障，参与者（RM）将一直处于锁定状态。
* 数据一致性问题：在阶段二中，如果发生局部网络问题，一部分参与者收到了提交消息，另一部分没收到，会导致节点间数据不一致。

## Seata XA 模式深度解析

XA 模式是从 1.2 版本支持的事务模式，Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。Seata 对 XA 模式进行了封装，使其更易于在微服务架构中使用。

主要特点：

* 采用 `DataSourceProxyXA` 作为数据源代理，替代AT模式的 `DataSourceProxy`
* 通过 `@GlobalTransactional` 注解标记分布式事务入口
* 在第一阶段，RM 执行业务 SQL 但不提交，只注册分支事务
* 在第二阶段，由 TM 根据分支状态决定提交或回滚

### Seata架构与 XA 模式流程

![image.png](https://blog.liushigong.cn/static/img/bc10106c848bb9e2dc50b873b2ef44f7.image.webp)

在 Seata 定义的分布式事务框架内，XA 模式利用事务资源（数据库等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务。

**执行阶段（Execute）：**

* **开启全局事务**：TM 向 TC（Seata-Server）发起全局事务的开启请求，TC生成全局唯一的XID。
* **注册分支事务**：每个 RM 执行业务 SQL 前，会向TC注册分支事务，并将XID与本地事务关联。
* **执行SQL并准备**：RM执行业务SQL，但不提交（数据库层面由XA驱动管理），然后执行xa\_prepare（或等效操作）。

报告状态：RM 将本地事务执行状态（成功或失败）报告给 TC。

**完成阶段（Finish）：**

* **TC决策**：TC 根据所有分支事务的报告状态决定全局事务是提交还是回滚。
* **提交/回滚**：TC 通知所有 RM 执行 `xa_commit` 或 `xa_rollback`。
* **资源释放**：RM 完成最终操作并释放事务资源。

Seata XA 模式的数据源代理设计对开发者友好，旨在透明化 XA 编程模型。它支持基于普通 DataSource 创建 XA 连接，无需开发者专门配置 XADataSource

### Seata XA 模式存在的问题

#### 数据锁定

数据在整个事务处理过程结束前，都被锁定，读写都按隔离级别的定义约束起来。

思考

数据锁定是获得更高隔离性和全局一致性所要付出的代价。

补偿型 的事务处理机制，在 执行阶段 即完成分支（本地）事务的提交，（资源层面）不锁定数据。而这是以牺牲 隔离性 为代价的。

另外，AT 模式使用 全局锁 保障基本的 写隔离，实际上也是锁定数据的，只不过锁在 TC 侧集中管理，解锁效率高且没有阻塞的问题。

#### 协议阻塞

XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。

思考

协议的阻塞机制本身并不是问题，关键问题在于 协议阻塞 遇上 数据锁定。

如果一个参与全局事务的资源 “失联” 了（收不到分支事务结束的命令），那么它锁定的数据，将一直被锁定。进而，甚至可能因此产生死锁。

这是 XA 协议的核心痛点，也是 Seata 引入 XA 模式要重点解决的问题。

基本思路是两个方面：避免 “失联” 和 增加 “自解锁” 机制。

#### 性能差

性能的损耗主要来自两个方面：一方面，事务协调过程，增加单个事务的 RT；另一方面，并发事务数据的锁冲突，降低吞吐。

思考

和不使用分布式事务支持的运行场景比较，性能肯定是下降的，这点毫无疑问。

本质上，事务（无论是本地事务还是分布式事务）机制就是拿部分 **性能的牺牲** ，换来 编程模型的简单 。

与同为 业务无侵入 的 AT 模式比较：

首先，因为同样运行在 Seata 定义的分布式事务框架下，XA 模式并没有产生更多事务协调的通信开销。

其次，并发事务间，如果数据存在热点，产生锁冲突，这种情况，在 AT 模式（默认使用全局锁）下同样存在的。

所以，在影响性能的两个主要方面，XA 模式并不比 AT 模式有非常明显的劣势。

AT 模式性能优势主要在于：集中管理全局数据锁，锁的释放不需要 RM 参与，释放锁非常快；另外，全局提交的事务，完成阶段 **异步化**。

### Seata XA 模式的优缺点

**优点：**

* 强一致性：得益于 XA 协议，满足 ACID 特性。
* 数据库支持广泛：主流支持 XA 协议的数据库均可使用。
* 低侵入性：开发者通常只需关注 `@GlobalTransactional` 注解，无需深入修改业务代码。

**缺点：**

* 性能开销：一阶段需要锁定数据库资源，直到二阶段结束才释放，在高并发场景下对性能影响较大。
* 依赖数据库 XA 支持：其能力依赖于底层数据库对 XA 协议的实现质量。

## Spring Cloud Alibaba 集成 Seata XA 模式实战

接下来我们设计一套基于 Seata XA 模式的分布式事务实现方案。

**环境准备**

* Seata Server (TC)：已部署并运行，并使用 Nacos 作为注册中心和配置中心。
* 支持XA的数据库：如MySQL 5.7.17及以上版本。

基于 Spring Cloud Alibaba 构建 cloud-seata-xa 项目，模块如下

* cloud-seata-xa-order
* cloud-seata-xa-account
* cloud-seata-xa-storage

代码实现可下载 [cloud-seata-xa](https://gitee.com/liushigong/distributed-transaction/tree/master/cloud-seata-xa)

提示

从编程模型上，XA 模式与 AT 模式保持完全一致，只需要修改数据源代理，即可实现 XA 模式与 AT 模式之间的切换。

**Naocs 配置**

在同分组下，根据服务中 `seata.service.vgroup-mapping` 定义的分组名称配置信息，内置的文本为集群名称 `default`。

```
yml

seata:
  # 是否开启spring-boot自动装配 默认true
  enabled: true
  # 是否开启数据源自动代理 默认 true
  enable-auto-data-source-proxy: true
  # 是否使用JDK代理作为数据源自动代理的实现方式,默认false,采用CGLIB作为数据源自动代理的实现方式
  use-jdk-proxy: false
  # 数据源代理模式 默认 AT
  data-source-proxy-mode: XA
  # Seata 应用ID，默认${spring.application.name}
  application-id: ${spring.application.name}
  # 事务分组 - 用于TC集群名
  tx-service-group: seata-xa-group
  # 添加以下配置
  service:
    vgroup-mapping:
      seata-xa-group: default  # 你的事务分组对应的集群名称
    disable-global-transaction: false
```

![image.png](https://blog.liushigong.cn/static/img/36717ea70069ea362f92e6ba4410567e.image.webp)

## XA模式优缺点与适用场景

### 优点总结

* 强一致性：严格遵循ACID，数据一致性高。
* 模型简单：理解和使用相对简单，尤其是与Seata集成后。
* 数据库原生支持：依赖数据库自身XA实现，稳定可靠。
* 无代码侵入（低侵入）：业务代码几乎无需为分布式事务做额外修改。

### 缺点总结：

* 性能瓶颈：同步阻塞和资源锁定时间长，吞吐量低，不适合高并发场景。
* 依赖数据库：性能和质量受数据库XA实现影响。
* 单点问题：TM（协调者）宕机可能导致资源阻塞（虽然后续有Seata TC保障，但传统2PC存在此问题）。

### 适用场景

* 对强一致性要求极高的业务场景，如金融核心交易。
* 事务执行时间相对确定且较短的操作。
* 系统并发量不是极端高，可以接受XA协议性能损耗的场景。

## 总结

XA 协议通过两阶段提交（2PC） 机制，为分布式事务提供了强一致性的保证，是分布式事务领域经典且重要的解决方案。Seata 框架对 XA 进行了封装和优化，降低了开发复杂度，使得开发者能够通过简单的注解和配置，快速在微服务体系中引入强一致性分布式事务能力。

然而，XA 协议的同步阻塞和性能问题也是其固有的局限性。因此，在选择分布式事务方案时，需要根据实际业务场景对一致性和性能的要求进行权衡。对于追求高性能和最终一致性的场景，可以考虑 Seata 的 AT 模式或TCC 模式等柔性事务方案。

XA 强一致性分布式事务原理与实战

每次学习的过程中，我都会构建自己的思维模型，从一个点，引出另外的点，以点成面。接下来我们将从分布式的 CAP/BASE 理论基础去思考构建自己的分布式事务思维模型。

## 分布式的理论基础

既然是分布式，那就离不开分布式的理论基础：CAP、BASE 理论，其中 **分布式事务的本质** 也是基于此理论基础进行实现的，

### CAP 原理：鱼和熊掌不可兼得

想象一下，你有一个超市，超市中有一台收银机（单机系统），现在要开连锁店，每个连锁店中都有自己的收银机（分布式系统），由于超市遍布不同区域，管理起来特别麻烦，所以你将连锁店中的收银机器进行联网同步商品价格的调整（做好准备发车了），你会遇到几个核心矛盾：

* **数据一致性 (Consistency)：** 你希望所有分店的商品库存和价格数据都是一模一样的。顾客无论在哪个分店查，看到的价格和库存都是统一的，不会出现A店显示有货，B店显示无货的尴尬情况。
* **服务可用性 (Availability)：** 你希望每一个分店在任何时候都能正常营业，接待顾客，不能动不动就关门盘点（服务宕机）。
* **分区容错性 (Partition Tolerance)：** 分店之间是靠网络联系的，万一某个分店和总部的网络断掉了（比如挖断了光缆），或者分店和分店之间联系不上了（网络分区），整个连锁系统不能就此瘫痪，就算价格无法同步与总部不一致，也得能继续扛下去。

在上述的矛盾中，**分区容错性是必须要保障的**，因为网络总会出问题，总不能网断了就不营业了，所以你只能在`数据一致性 Consistency（简称 C）` 和 `服务可用性 Availability（简称 A）` 之间二选一。

这就是 CAP 原理，它其实就告诉我们，在分布式系统里，上面这三个美好的愿望你不可能同时全部满足，就像三角形的三个角，你最多只能选择两个。

![image.png](https://blog.liushigong.cn/static/img/640485eaa5f8d18642812c3aa89c8a9c.image.webp)

这就是我们常说的 **CP模型、AP模型**，也俗称 “鱼与熊掌不可兼得”

* CP模型（一致性+分区容错性）：为了保障所有分店数据绝对一致，我宁愿暂时让某个网络断掉的分店停止服务（不可用），直到数据同步成功。这适用于对数据准确性要求极高的场景，比如银行转账。
* AP模型（可用性+分区容错性）：为了保障每个分店都能随时提供服务，我允许数据暂时有一点不一致。比如某个分店网络断了，它先用自己的旧价格卖着，等网络恢复了再同步新数据。这适用于对体验要求高的场景，比如电商商品浏览、点赞收藏。

### BASE 理论：学会妥协

BASE 理论其实就是在 **AP模型** 下的实践和补充，为了保证一致性的一种妥协方式，其 **本质就是为了保障数据的最终一致性，也就是允许数据短暂时间的不一致，最终都会达到一致性**。好比上述我们的连锁店，网路断开只是一时的，总有修复的时候，彼时数据就会同步完成，达到与总部价格一致。

BASE 单词拆开来看，就是其 BASE 理论的实现原理

* Basically Available（基本可用 BA）：系统大部分时间能用就行
* Soft state（软状态 S）：允许数据暂时不一致
* Eventually consistent（最终一致 E）：最终数据会变得一致

我们不强求数据时刻都强一致（Basically Available），但可以允许系统存在中间状态（Soft state），但经过一小段时间后，数据最终会达到一致（Eventually consistent）。

提示

分布式事务的本质，就是在 CP 和 AP 之间做权衡，并基于BASE理论来实现最终一致性的方案。既然知道了基础理论中只有CP 和 AP 两种模型，那对应的分布式事务的解决方案也无非是这2种：

* 强一致性解决方案
* 最终一致性的解决方案。

## 强一致性解决方案

强一致性的解决方案是基于 CAP 原理中的 **CP模型** 进行实现的，它要求所有参与方必须同时成功或同时失败，任意时刻查询参与全局事务的各节点的数据都是一致的，保证了数据的强一致性，但可能会牺牲一些可用性。

此方案主要 **适用于对数据一致性要求高，在任意时刻都要查询到最新写入数据的场景**，比如跨行转账业务

其优点是数据一致性高，在任意时刻都能够查询到最新写入的数据。不过其缺点也很明显，在写入期间不可读取，需要等待写入完成，在分布式事务未完全提交和回滚之前，应用程序不会查询到最新的数据，牺牲了性能和可用性，不适合高并发场景

### DTP （Distributed Transaction Processing）模型

DTP（Distributed Transaction Processing），即分布式事务处理模型，是由X/Open组织（后来的Open Group）定义的一套标准架构。它定义了在分布式系统中，多个资源（如数据库、消息队列）如何协同参与一个全局事务，并保证 ACID 特性的理论模型。

其本质就是一种全局事务模型，可以把它理解为分布式事务的“顶层设计”或“蓝图”。它不关心具体如何实现，而是定义了有哪些角色以及角色之间如何交互。

推荐阅读：[《Distributed Transaction Processing:
The XA Specification》](https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf)

#### 五大核心组件

* **应用程序 (Application Program, AP)：** 一个应用程序就是一个实例，负责发起事务
* **资源管理器 (Resource Manager, RM)：** 主要管理自身资源，执行实际的事务操作（如修改数据），并处理与事务相关的指令（如准备、提交、回滚）。一个全局事务通常涉及多个RM。
* **事务管理器 (Transaction Manager, TM)：** 分布式事务的大脑和总协调者。它是一个独立的组件。

  + 为整个全局事务分配一个唯一的全局事务ID (XID)。
  + 协调所有参与事务的RMs，驱动它们最终一起提交或一起回滚。
  + 负责执行2PC协议。TM是2PC协议的执行者。
* **通信资源管理器 (Communication Resource Manager, CRM)：** 管理分布式系统中不同节点（AP、TM、RM可能不在同一台机器上）之间的通信。协调不同节点/进程间的交互，确保消息能够正确传递。通常由底层中间件（如TPMonicitor）实现，对开发者透明。
* **通信协议 (Communication Protocol, CP)：** 定义了TM、RM、AP之间相互通信的接口和规则。最重要的协议：就是 XA 协议，它定义了 TM 和 RM 之间的交互接口。

![image.png](https://blog.liushigong.cn/static/img/c2db86cd833c0da446dc6293e1bdb905.image.webp)

在 DTP 模型中，AP 向 TM 注册一个全局事务，然后通过 RM 的接口访问资源。TM 通过 XA 接口（属于CP）来协调和管理所有注册到这个全局事务中的 RMs。CRM 为整个交互过程提供通信支持。

一个全局事务的成功与否，取决于一个个 RM 资源管理器的内部工作的操作是否成功，还取决于其他资源管理器的操作。如果任何操作在任何地方失败，那么每个参与的 RM 资源管理器必须回滚它为全局事务做的所有操作。

一个资源管理器通常不知道其他资源管理器做了什么工作。TM 事务管理器告诉每个资源管理器全局事务的存在，并协调它们完成这些事务。一个资源管理器负责把它的可恢复的工作单元映射到全局事务。

理解其工作原理

用一个电商场景中的下单做为场景，一个下单业务中可能要求更新几个不同的数据库，应用系统中任何地方发生的工作都必须原子提交，同时每个 RM 都必须让 TM 协调全局事务中包含的 RMs 的可恢复工作单元，保证失败后的回滚操作。

#### XA 规范

**XA 规范是 DTP 模型的核心实现方式。** 它是由X/Open定义的 TM 与 RM 之间的接口规范。一套遵循 XA 规范的 API，通常以 xa\_ 开头，例如：

* xa\_start：开启一个事务分支，将RM关联到全局事务XID上。
* xa\_end：结束事务分支。
* xa\_prepare：询问RM是否准备好提交（2PC的第一阶段）。
* xa\_commit：通知RM提交事务（2PC的第二阶段）。
* xa\_rollback：通知RM回滚事务。
* xa\_recover：用于恢复宕机时未完成的事务。

其工作流程如下：

* AP（你的程序）通过TM（如一个Java事务管理器）声明一个全局事务。
* AP 通过数据库驱动（作为 RM 的代理）执行 SQL。执行前，驱动会调用 `xa_start` 将当前连接与全局事务XID 绑定。
* AP 结束时，通知 TM，而 TM 开始执行 2PC 协议：

  + 第一阶段：TM 调用所有参与 RM 的 `xa_prepare` 方法。各 RM 将事务内容持久化到磁盘（Redo Log），并锁定资源，然后返回是否成功。
  + 第二阶段：如果所有 RM 都 prepare 成功，TM调 用所有 RM 的 `xa_commit` 方法提交；如果任何一个失败，TM 调用所有 RM 的 xa\_rollback 方法回滚。

2PC、3PC 协议

**2PC/3PC 其实是 DTP 里 TM 控制提交的具体算法实现** ，掌握上面 DTP 模型后，在看这句话就能把 DTP 和 2PC 串起来了。3PC 作为 2PC 的优化版本，也得点出改进点和代价。

2PC（两阶段提交）是 DTP 中最常用的协议，分两步，就像组织聚会：

* 准备阶段：问各部门"能参加吗？"，各部门先准备但不正式确定
* 提交阶段：如果都同意，就正式确定；如果有人不同意，就全部取消

先问"下周六能来吗？"，如果都答应，就发邀请函；如果有人不能来，就取消聚会。

3PC（三阶段提交）是 2PC 的改进版，增加了"预准备"阶段，避免了 2PC 中"等待"的尴尬情况。
就像组织聚会时，先问"下周六有空吗？"，如果都回答"有空"，再问"确定能来吗？"，最后才发邀请。

强一致性解决方案保证了数据的绝对一致，但代价是系统可能在等待过程中变得"慢"或"不可用"，就像聚会组织者要等所有人确认后才能发邀请，如果有人迟迟不回复，聚会就一直等。

主流数据库（MySQL InnoDB, Oracle, PostgreSQL等）都提供了对 XA 规范的支持。

在 Java 中，JTA (Java Transaction API) 是 XA 规范的Java版实现，而像 Atomikos、Narayana这样的库就是实现了 JTA 的TM，还有 Dromara 开源社区的 RainCat 框架也在应用层支持 XA 规范。

### 小总结

通过本文对 DTP 的讲解，能认识到 **强一致性解决方案的实现方式与执行流程**，其中了解到 `DTP 模型`、`XA 规范`、`2PC 协议`、`3PC 协议` 这是一个概念层级的问题。

* **DTP 模型** 是一个分布式事务的架构模型，一个设计蓝图，定义了AP, RM, TM, CRM, CP 五大角色
* **XA 规范** 定义了接口协议，是 DTP 模型中 CP (通信协议) 的核心实现，定义了 TM 与 RM 的交互标准
* **2PC 和 3PC** 是具体的协议，是算法，是 TM 用来协调 RMs 完成分布式事务的具体实现方法。

**在 DTP 模型中，事务管理器 (TM) 使用 2PC（或3PC）这个协议作为其协调资源管理器 (RMs)的核心机制，实现强一致性解决方案的。**

整体来看，强一致性分布式事务解决方案要求参与事务的各个节点的数据时刻保持一致，查询任意节点的数据都能得到最新的数据结果。这就导致在分布式场景，尤其是高并发场景下，系统的性能受到影响

## 最终一致性解决方案

最终一致性分布式事务解决方案是基于 **AP + BASE 理论** 为基础，并不要求参与事务的各节点数据时刻保持一致，允许其存在中间状态，只要一段时间后，能够达到数据的最终一致状态即可，这也是互联网公司最常用的模式。

在实现最终一致性时，有几个通用的保护措施是一定要考虑的：

* **唯一性标识的可查询操作：** 给每一笔分布式事务发一个唯一的“身份证号”（全局事务ID），凭这个号可以查到事务到底进行到哪一步了，是成功还是失败。
* **同一业务处理的幂等操作：** 因为网络可能重试，同一个请求可能会来很多次。所以要保证无论来多少次，最终的结果都和只来一次一样。比如扣款操作，即使因为超时重试了，也只能扣一次钱。
* **事务调用异常的监控与告警操作：** 要有完善的监控系统，一旦发现某个事务卡住了或者失败了，要能立刻报警通知程序员小哥来“救火”。
* **针对本次业务事务数据的补偿操作：** 做错了就要认，挨打了要立正。如果事务失败了，一定要有一个反向操作来“擦屁股”，比如刚才扣了钱，现在就要把的钱加回去，这叫补偿。

目前主流的最终一致性解决方案实现方式有以下三种，此处都是简单过下，在思考最终一致性时能立马构思出其解决方案，后续会有专门的章节讲解源码级的实现，在想到其方案能立马构思出其源码实现：

* TCC 方案
* 可靠消息投递方案
* 最大努力通知型方案

### TCC（Try-Confirm-Cancel）方案

TCC就是一个典型的“补偿型”选手，它把一件事分成三个步骤：

![image.png](https://blog.liushigong.cn/static/img/4f34f04d90cb9a0ade7aadfa526d55f9.image.webp)

* **Try (尝试)：** 预留资源。

  比如下单减库存场景，假设有100件可售库存，当下单后是先锁定10件库存，后续下单需要从100件中减去10件锁定库存，还剩下90件可售库存，此时订单状态为待确认。
* **Confirm (确认)：** 确认操作。

  如果所有参与方的 Try 预留资源操作都成功了，就执行真正的确认操作。比如把冻结的10件库存真正扣掉，那可售库存就是90件，此时订单状态改为已确认。
* **Cancel (取消)：** 补偿操作。

  如果 Try 阶段有任何一个失败，就执行 Cancel，释放之前冻结的所有资源。比如把冻结的10件库存释放回可售库存里。

整体来看，TCC 对业务代码侵入性强，需要你专门写 Try、Confirm、Cancel三个接口。它的好处是性能好，数据最终一致性强。坏处是开发工作量比较大。

### 可靠消息投递

这个方案的核心是找一个无比靠谱的“邮差”（消息队列） 来帮忙传递事务消息。

![image.png](https://blog.liushigong.cn/static/img/f9594614685d0e2ade8c189ffe95c82f.image.webp)

1. 事务发起方先往消息队列发一条“预备消息”。
2. 消息队列保存好这条消息，但此时消费者还看不到它。
3. 消息队列回复发送方“预备成功”。
4. 发送方执行本地事务（比如扣款）。
5. 如果本地事务成功，就通知消息队列“请发布消息”；如果失败，就通知“删除消息”。
6. 消息队列收到“发布”指令后，才让消费者看到这条消息。
7. 消费者处理消息（比如扣库存），如果处理成功，消息就被消费掉；如果失败，消息队列会重投这条消息，直到成功。

**可靠消息方案需要解决两个问题：**

* 本地事务与消息发送的原子性：确保"扣款"和"发消息"同时成功或失败
* 事务参与方接收消息的可靠性：确保朋友能收到消息，如果没收到可以重试

![image.png](https://blog.liushigong.cn/static/img/ca3f59d8013b9e17244922836b985f33.image.webp)

这种方式依靠消息队列的可靠性，保证了只要消息发出去了，最终就一定能被处理。它非常适合异步场景，比如下单后发优惠券、通知物流系统等。它的缺点是整个流程比较长，时效性没那么高，如果超过重试次数还未执行成功，需要人工干预。

### 最大努力通知

这是要求最低的一种最终一致性方案，常见于外部系统调用，比如通知支付结果。

![image.png](https://blog.liushigong.cn/static/img/187a60c19942bb39c8afe1805eda5a55.image.webp)

1. 服务A（比如支付系统）完成任务后，会一次又一次地（最大努力）调用服务B（比如订单系统）提供的接口，告诉它处理结果。
2. 服务B收到通知后，处理完返回一个成功响应。
3. 如果服务A一直没收到成功响应，就会按照策略反复重试（比如隔1s、5s、10s...重试），直到达到重试次数上限为止。

最大努力通知这个方案的目标是“通知到”，但不保证100%成功。下游服务的接口必须做好幂等。即使通知失败了，也需要有对账机制来最终修正数据。这是一种业务容忍度最高、实现也相对简单的方案，但可靠性稍低。适合对一致性要求不那么高的场景，比如通知类业务。

最大努力通知的关键是"不断重试"和"人工兜底"。虽然不能保证100%成功，但通过不断重试和人工干预，可以达到较高的成功率。

## 总结

分布式事务的思维模型其实很简单：要么追求强一致（CP），要么追求最终一致（AP）。

**理论基石：**

分布式系统只能在CP（强一致）和AP（最终一致）中做选择（CAP理论），而 BASE 理论是 AP 方向的最佳实践指南。

**两大阵营：**

* 强一致性(CP)：强一致性解决方案（DTP、2PC、3PC）保证了数据绝对一致，但代价是系统可能变得"慢"或"不可用"，适合金融交易等对一致性要求高的场景。
* 最终一致性(AP)：是互联网主流选择，牺牲了实时一致性，但换来更高的可用性和更好的性能，适合电商、社交等对一致性要求不那么高的场景。旗下有三大将，对于选择哪种方案，要看你的业务需求：

  + TCC：通过代码手动管理事务流程和补偿，控制力强，性能好，但开发麻烦。
  + 可靠消息：依靠可靠的消息队列异步驱动事务，解耦效果好，通用性强。
  + 最大努力通知：适用于外部通知，简单粗暴，保证“尽力而为”，需配合对账。

有了这个思维模型，你就能理解各种分布式事务框架（如Seata、RocketMQ事务消息）的设计初衷和适用场景了。 在接下来的文章中，我们将深入这些方案的实现原理，看看主流框架是如何玩转这些模型的，以及在实际业务中我们该如何根据场景进行选型。

构建自己的分布式事务底层实现的思维模型

在现代企业级应用系统中，数据权限隔离是保障业务安全的核心需求之一。随着业务规模的扩大，系统往往需要支持多区域、多项目公司的数据隔离能力，例如某位业务人员只能查看所属区域的订单数据。本文将分享如何通过自定义 Spring MVC 参数解析器与 Redis 缓存机制，实现对分页接口的精细化数据权限控制方案，并附完整代码示例。

## 需求背景

在现有分页查询接口中，业务人员可能拥有跨区域、跨项目公司的数据访问权限，这可能导致敏感数据泄露或越权操作。例如：

* 财务人员A仅负责华东区域，却能查询全国所有订单；
* 项目公司B的业务员可访问其他公司的客户数据。

为解决上述问题，需实现以下目标：

* **权限动态配置**：通过管理后台为用户分配区域/项目公司权限；
* **数据自动过滤**：接口调用时自动注入用户权限范围内的数据标识；
* **无侵入改造**：不修改现有业务代码，仅扩展权限逻辑。

## 实现思路

传统的权限控制通常在 Service 层或 DAO 层实现，但这样会导致业务代码与权限代码耦合度过高。根据需求内容进行思考，在技术层面上实现方式如下：

| 实现方式 | 优点 | 缺点 |
| --- | --- | --- |
| 处理器拦截器 `HandlerInterceptor` | 可以对请求预处理、后处理、还有结束后处理 | 无法对直接获取到请求参数对象，需要各种反射获取 |
| AOP 拦截，通过反射赋值 | 直观、快捷，更多的拦截方式处理 | 拦截的 controller 扫描接口太多，浪费内存，每个接口都会拦截一次 |
| 自定义参数解析器 `HandlerMethodArgumentResolver` | 在请求时直接注入参数，无需转换 | 实现复杂度高 |

最终我选择在 Web 层通过自定义参数解析器实现数据权限的自动注入，具有以下优势：

* **解耦合**：权限逻辑与业务逻辑分离
* **集中管理**：所有权限相关处理集中在一个地方
* **易于维护**：新增或修改权限逻辑只需调整解析器
* **低侵入性**：通过注解方式实现，不影响现有代码

### 权限数据存储

使用 Redis 的 Set 结构缓存用户权限，Key 格式为：`DATA_PERMISSION_CONFIG_KEY:{userId}:{fieldName}`，例如： `data_permission:1001:areaCodes` 存储用户 1001 的区域编码集合。

### 参数解析器改造

通过继承 Spring MVC 的 `RequestResponseBodyMethodProcessor`，实现自定义参数解析器：

* 权限注入时机：在请求参数反序列化后，通过反射动态填充权限字段；
* 字段匹配规则：优先匹配 DTO 类中定义的 companyCodes/areaCodes 字段。

### 注解设计

创建 `@DataPermissionBody` 注解标记需要权限注入的参数，其行为与 `@RequestBody` 类似，但具备权限处理逻辑。

### 数据绑定流程

在新增财务数据权限中，新增编辑删除项目公司都对应的添加到缓存中，请求接受时会根据 controller 层自定义注解进行参数解析，查询数据权限赋值到现有的查询对象中，实现数据权限的控制，绑定流程：`请求到达 → 参数解析器识别注解 → 从Redis加载权限数据 → 反射注入DTO字段 → 业务方法执行`

![image.png](https://blog.liushigong.cn/static/img/a45e517d46523f38fb9ffcedc7ddf959.image.webp)

## 代码实现

### 自定义参数解析器

默认的 `@ResponseBody` 注解参数解析器是 `RequestResponseBodyMethodProcessor`，我们调整的接口上都是基于此方式，所以对 `RequestResponseBodyMethodProcessor` 进行重写，来校验数据权限

```
java

public class DataPermissionMethodArgumentResolver extends RequestResponseBodyMethodProcessor {

    /**
     * Basic constructor with converters only. Suitable for resolving
     * {@code @RequestBody}. For handling {@code @ResponseBody} consider also
     * providing a {@code ContentNegotiationManager}.
     *
     * @param converters
     */
    public DataPermissionMethodArgumentResolver(List<HttpMessageConverter<?>> converters) {
        super(converters);
    }

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        // 判断是否包含数据权限类
        return parameter.hasParameterAnnotation(DataPermissionBody.class) && parameter.getParameterType().getSuperclass().isAssignableFrom(DataPermissionDTO.class);
    }

    /**
     * Throws MethodArgumentNotValidException if validation fails.
     *
     * @param parameter
     * @param mavContainer
     * @param webRequest
     * @param binderFactory
     * @throws HttpMessageNotReadableException if {@link RequestBody#required()}
     *                                         is {@code true} and there is no body content or if there is no suitable
     *                                         converter to read the content with.
     */
    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        // 获取参数
        Object resolveArgument = super.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
        try {
            // 反射设置给对象的父类属性
            Class<?> superclass = parameter.getParameterType().getSuperclass();
            for (Field declaredField : superclass.getDeclaredFields()) {
                // 获取数据权限
                Set<String> members = RedisTemplateHolder.redisTemplate().opsForSet().members(Constant.DATA_PERMISSION_CONFIG_KEY + CurrentUserContext.getUserId() + ":" + declaredField.getName());
                logger.info("数据权限：" + members);
                if (members != null && declaredField.getType().isAssignableFrom(List.class)) {
                    // 设置字段值
                    ReflectUtil.setAccessible(declaredField);
                    ReflectUtil.setFieldValue(resolveArgument, declaredField, new ArrayList<>(members));
                }
            }
        } catch (Exception e) {
            logger.error("数据权限参数解析异常", e);
        }
        return resolveArgument;
    }

    @Override
    protected boolean checkRequired(MethodParameter parameter) {
        DataPermissionBody requestBody = parameter.getParameterAnnotation(DataPermissionBody.class);
        return (requestBody != null && requestBody.required() && !parameter.isOptional());
    }
}
```

### 配置类注册解析器

将参数解析器添加到 MVC 配置中，实现 `addArgumentResolvers` 方法

```
java

@Configuration
public class BusinessWebMvcConfigurer implements WebMvcConfigurer {
    private List<HttpMessageConverter<?>> messageConverters;

    @Override
    public void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
        WebMvcConfigurer.super.extendMessageConverters(converters);
        this.messageConverters = converters;
    }

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(new DataPermissionMethodArgumentResolver(messageConverters));
    }
}
```

### 注解与DTO定义

定义数据权限的注解 `@DataPermissionBody`，其本质也就是换名的 `@ResponseBody`

```
java

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DataPermissionBody {
    /**
     * Whether body content is required.
     * <p>Default is {@code true}, leading to an exception thrown in case
     * there is no body content. Switch this to {@code false} if you prefer
     * {@code null} to be passed when the body content is {@code null}.
     * @since 3.2
     */
    boolean required() default true;
}
```

```
java

@Data
public class DataPermissionDTO extends PageReqDTO {
    /**
     * 项目公司编码
     */
    private List<String> companyCodes;
    
    /**
     * 区域编码
     */
    private List<String> areaCodes;
}
```

### 控制器使用示例

在使用的过程中，需要将接口的入参标记注解 `@DataPermissionBody`，并继承 `extends DataPermissionDTO`,这样入参对象中通过反射就被扩展了数据权限的参数

```
java

// 业务请求的 DTO
public class OrderRequestDTO extends DataPermissionDTO {
    // 业务字段定义...
}

@PostMapping(value = "/page")
public XEnergyResponse<PageResDTO<OrderPageRes>> page(@DataPermissionBody OrderRequestDTO req) {
    // 业务逻辑处理
}
```

## 总结

通过自定义 Spring MVC 参数解析器实现数据权限控制，我们成功构建了一个优雅、高效的解决方案。该方案具有以下优点：

* 解耦性强：权限逻辑与业务逻辑完全分离，符合单一职责原则
* 扩展性好：新增权限维度只需在 DTO 基类中添加字段并在 Redis 中配置
* 维护简单：权限逻辑集中处理，便于统一管理和优化
* 侵入性低：通过注解方式实现，对现有代码影响极小

在实际应用中，该方案能够有效支持多区域、多项目公司的数据隔离需求，为业务人员提供精确的数据访问控制。未来还可以进一步优化，如增加权限缓存、支持更复杂的权限规则等。

这种基于参数解析器的权限控制方案不仅适用于当前场景，也可以为其他类似的数据过滤需求提供借鉴，是 Spring MVC 高级应用的典型实践。

基于 Spring MVC 参数解析器实现数据权限隔离

在微服务架构盛行的今天，配置中心的使用已成为标配。Nacos 作为阿里巴巴开源的配置中心，提供了强大的动态配置管理能力。但在实际开发中，我们经常会遇到这样的场景：需要在工具类的静态方法中获取配置信息，同时还要保证配置能够动态刷新。这看似矛盾的需求——静态方法的"静态"特性与配置的"动态"刷新如何兼顾？本文将分享一种巧妙的设计方案，解决这一技术难题。

## 需求背景

在最近的项目需求设计阶段，我们遇到了一个典型场景：需要提供一个静态工具方法来调用第三方接口。这个工具方法需要读取 Nacos 中的配置属性，同时必须保证当 Nacos 中的配置发生变化时，能够实时获取最新的配置值。

看似简单的需求背后隐藏着两个技术挑战：

* 静态方法如何访问 Spring 容器管理的配置属性？
* 如何实现配置变更时的自动刷新机制？

## 实现思路

针对上述挑战，我们采用了以下设计方案：

1. 静态变量持有配置：使用静态变量保存配置对象，供静态方法访问
2. 实现 `ApplicationContextAware` 接口：获取 Spring 上下文，初始加载配置
3. 监听环境变更事件：通过 ApplicationListener 监听 `EnvironmentChangeEvent`，实现配置热更新
4. 前缀过滤机制：只关注与当前配置相关的变化事件，提高处理效率

这种设计巧妙地利用了 Spring 的事件机制，将配置的动态更新与静态方法的便捷性完美结合。

## 代码实现

```
java

@Slf4j
@Component
public class StudentUtils implements ApplicationContextAware, ApplicationListener<EnvironmentChangeEvent> {
    // 静态变量持有配置实例
    private volatile static StudentProperties properties;
    
    /**
     * 刷新环境配置
     * @param studentProperties 新的配置属性
     */
    public static void refreshEnvironment(StudentProperties studentProperties) {
        if (studentProperties != null) {
            properties = studentProperties;
            log.info("StudentProperties配置已刷新");
        }
    }
    
    /**
     * 示例工具方法 - 调用第三方接口
     */
    public static void callThirdPartyApi() {
        // 使用静态变量properties获取最新配置
        String apiUrl = properties.getApiUrl();
        String apiKey = properties.getApiKey();
        
        // 调用三方接口的逻辑...
        log.info("调用第三方接口: {}, Key: {}", apiUrl, apiKey);
    }
    
    // 其他工具方法...
    
    /**
     * 设置ApplicationContext，初始化配置
     */
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) {
        refreshEnvironment(applicationContext.getBean(StudentProperties.class));
    }
    
    /**
     * 处理环境变更事件
     */
    @Override
    public void onApplicationEvent(EnvironmentChangeEvent event) {
        // 环境配置变更处理
        if (event.getSource() instanceof ConfigurableApplicationContext) {
            // 只处理与StudentProperties相关的配置变更
            if (event.getKeys().stream().anyMatch(key -> key.startsWith(StudentProperties.PREFIX))) {
                ConfigurableApplicationContext context = (ConfigurableApplicationContext) event.getSource();
                refreshEnvironment(context.getBean(StudentProperties.class));
                log.debug("检测到配置变更，已刷新StudentProperties");
            }
        }
    }
}
```

配套的配置属性类：

```
java

@ConfigurationProperties(prefix = "student")
@Data
public class StudentProperties {
    public static final String PREFIX = "student";
    
    private String apiUrl;
    private String apiKey;
    private Integer timeout;
    // 其他配置项...
}
```

## 实现解析

### 配置初始化流程

* 项目启动时，Spring容器初始化 StudentUtils 组件
* 通过 `setApplicationContext` 方法获取 StudentProperties 实例
* 调用 `refreshEnvironment` 方法初始化静态配置变量

### 动态刷新流程

* 当 Nacos 中配置发生变化时，Spring发布 `EnvironmentChangeEvent` 事件
* `onApplicationEvent` 方法捕获事件并检查是否与当前配置相关
* 如果相关，重新从容器中获取配置 Bean 并更新静态变量

### 线程安全考虑

在实际生产环境中，需要考虑配置更新的线程安全性。可以通过以下方式增强：

```
java

public static void refreshEnvironment(StudentProperties studentProperties) {
    if (studentProperties != null) {
        // 使用volatile关键字保证可见性，或使用原子引用
        properties = studentProperties;
        log.info("配置已刷新，新API URL: {}", studentProperties.getApiUrl());
    }
}
```

## 总结

本文介绍了一种在静态方法中实现 Nacos 配置动态刷新的解决方案，具有以下优点：

1. **解耦设计**：工具类与具体配置实现解耦，便于测试和维护
2. **实时更新**：利用 Spring 事件机制实现配置热更新，零延迟
3. **高效过滤**：通过前缀过滤避免不必要的配置刷新操作
4. **简洁易用**：对外提供透明的静态方法调用方式

这种设计模式不仅适用于 StudentUtils 场景，还可以推广到任何需要在静态方法中访问动态配置的场景，如各种工具类、客户端初始化等。

通过本文的方案，我们成功解决了静态方法与动态配置之间的矛盾，为项目提供了一种可靠、高效的配置管理方式。在实际项目中，这种设计已经得到了验证，能够稳定支持配置的动态更新需求。