摘要：在当今互联网软件开发的大环境下，微服务架构盛行，越来越多的项目基于 Spring Boot3 框架搭建。在这样的项目中，分布式事务和本地事务的合理运用及避免它们之间的冲突，成为了开发过程中的关键挑战。今天，就让我们深入探讨一下在 Spring Boot3 中如

在当今互联网软件开发的大环境下，微服务架构盛行，越来越多的项目基于 Spring Boot3 框架搭建。在这样的项目中，分布式事务和本地事务的合理运用及避免它们之间的冲突，成为了开发过程中的关键挑战。今天，就让我们深入探讨一下在 Spring Boot3 中如何巧妙地应对这一难题。

（一）本地事务

在单体应用时代，本地事务是开发者们的得力助手。依赖于数据库强大的 ACID 特性，开发者仅需使用一个简单的@transactional注解，或者BEGIN TRANSACTION语句，就能轻松确保一组数据库操作要么全部成功，要么全部回滚。它就像是一个紧密协作的小团队，团队成员（即数据库操作）之间的配合默契，在事务这个 “指挥官” 的带领下，保证了数据操作的完整性和一致性。

（二）分布式事务

然而，随着微服务架构的兴起，一个业务流程往往需要跨越多个服务和数据库。这时，传统的本地事务就显得力不从心了，分布式事务应运而生。分布式事务如同一个大型交响乐团，各个服务和数据库是乐团中的不同乐器组，事务协调者则是乐团的指挥家。它需要协调多个位于不同节点的事务参与者，确保整个业务流程的操作在所有节点上要么全部成功提交，要么全部失败回滚。但这个过程远比本地事务复杂，网络不稳定、服务宕机、并发冲突等一系列问题，都像隐藏在暗处的 “小怪兽”，随时可能跳出来破坏事务的一致性。

在分布式事务中，有全局事务和分支事务之分。全局事务是整个分布式事务的 “总指挥”，而分支事务则是分布式事务中包含的每个子系统中的事务，它们在全局事务的协调下协同工作。基于 CAP 定理和 BASE 理论，衍生出两种解决分布式事务的思想：最终一致，即各分支事务各自提交，如果有不一致的情况，再想办法恢复数据；强一致，各分支事务执行完不要提交，等待彼此结果，然后再统一提交或回滚。

（一）资源竞争

当分布式事务和本地事务同时访问和修改相同的数据库资源时，就像两个人同时去抢同一个玩具，冲突很容易发生。例如，在一个电商系统中，本地事务可能正在处理用户的订单支付，而分布式事务可能在进行库存的扣减和物流信息的更新，它们都涉及到对商品库存表的操作。如果没有合理的协调机制，就可能出现数据不一致的情况，比如订单支付成功了，但库存却没有及时扣减。

（二）事务传播机制混乱

Spring Boot 提供了多种事务传播机制，如PROPAGATION_REQUIRED（默认值，如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务）、PROPAGATION_REQUIRES_NEW（创建一个新的事务，如果当前存在事务，则将当前事务挂起）等。当在复杂的业务调用链中，对这些事务传播机制使用不当，就如同在十字路口没有交通规则，车辆随意行驶，必然会导致混乱。比如，一个方法本应该在新的事务中执行，但由于错误地使用了PROPAGATION_REQUIRED，结果加入了一个不相关的现有事务，从而引发冲突。

（三）分布式事务框架与本地事务配置不兼容

在引入分布式事务框架（如 Seata）的同时，如果没有对其与本地事务的配置进行妥善调整，也会引发冲突。不同的分布式事务框架有其自身的特点和运行机制，与 Spring Boot 默认的本地事务配置可能存在不匹配的地方。例如，Seata 的 AT 模式在处理事务回滚时，依赖于对 SQL 的解析和镜像数据，如果本地事务的一些配置影响了 SQL 的执行或数据的获取，就可能导致分布式事务和本地事务在回滚操作上出现冲突。

Seata 是阿里巴巴开源的一款强大的分布式事务解决方案，它就像是一位经验丰富的 “大管家”，为分布式事务处理提供了高效可靠的途径。Seata 有三个基本组成部分：事务协调器（TC）、事务管理器（TM）和资源管理器（RM）。

TC 如同分布式事务的 “指挥官”，负责管理全局的分支事务状态，掌控着全局性事务的提交和回滚操作。在整个分布式事务流程中，它维护着全局事务和分支事务的状态信息，确保各个分支事务能够协同工作，最终达成事务的一致性。TM 则负责定义全局事务的范围，开始全局事务、提交或回滚全局事务，它就像是一个项目的负责人，把控着事务的整体流程。RM 管理分支事务处理的资源，与 TC 交流以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚，它是具体事务操作的执行者。

在 Spring Boot3 中集成 Seata 非常方便，开发者只需要在业务方法上使用@GlobalTransactional注解即可。Seata 会自动管理分布式事务的整个生命周期，包括全局事务的开始、提交或回滚，以及分支事务的注册、状态报告和提交或回滚。同时，要确保 Feign 支持事务上下文传递，必要时可禁用 Hystrix 以避免其对事务传递的干扰。通过观察各个服务的操作是否符合事务一致性要求，以及出现异常时事务是否能正确回滚，来验证分布式事务是否正常工作。

Seata 的 AT 模式具有无业务侵入、易于使用等优势。开发者无需在业务代码中编写复杂的事务回滚逻辑，Seata 通过自动补偿机制实现数据回滚，大大降低了开发成本和出错概率。只需在需要分布式事务的方法上添加@GlobalTransactional注解，即可轻松开启分布式事务，对现有业务代码的改动较小。不过，在高并发场景下，由于 AT 模式依赖全局锁，可能会引发锁竞争。此时，可以通过调整锁超时时间，或者在必要时切换为 TCC 模式等方式进行优化。同时，远程服务需支持幂等操作，即多次执行相同操作的结果应保持一致。通常可以通过唯一业务 ID 等方式来实现幂等性，避免重复提交导致的数据不一致问题。业务代码需显式抛出异常以触发事务回滚，避免try - catch语句吞没异常，导致事务无法正确回滚。

正确地选择和配置事务传播机制，是避免事务冲突的重要手段。在 Spring Boot 中，事务传播机制由Propagation枚举类中的常量表示，常见的有以下几种：

PROPAGATION_REQUIRED（默认值）：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是最常用的事务传播行为，适用于大多数需要保证一组操作原子性的场景。比如，在一个订单处理服务中，创建订单、更新用户积分等操作通常在同一个事务中进行，使用PROPAGATION_REQUIRED可以确保这些操作要么全部成功，要么全部失败。

PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。这种传播机制适用于一些对事务要求不严格的辅助操作，比如记录日志。如果当前有事务，那么记录日志的操作可以在事务内进行，以保证日志与业务操作的一致性；如果没有事务，记录日志的操作也可以独立执行，不影响业务流程。

PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。该传播机制适用于那些必须在事务环境中执行的方法，比如一些涉及到敏感数据修改的操作，确保数据的一致性和完整性。

PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则将当前事务挂起。当你希望某个方法的事务完全独立于调用它的方法的事务时，可以使用这种传播机制。例如，在一个支付系统中，支付操作可能需要一个独立的事务，即使调用支付方法的上层业务逻辑处于一个事务中，也不能影响支付事务的独立性。

PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，则将当前事务挂起。适用于一些不需要事务管理的操作，比如查询一些只读数据，为了提高性能，可以避免在事务中执行。

PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。用于明确禁止在事务环境中执行的方法。

PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行；如果当前没有事务，则创建一个新的事务。嵌套事务可以独立于外部事务回滚或提交，但如果外部事务回滚，所有更改也会被回滚。这种传播机制在一些复杂的业务场景中很有用，比如在一个订单处理流程中，可能有一些子操作可以独立回滚，但如果整个订单处理失败，这些子操作也需要回滚。

在实际应用中，开发者需要根据具体的业务需求，仔细选择合适的事务传播机制。配置事务传播行为通常通过在服务层的方法上使用@Transactional注解，并设置propagation属性来实现。例如：

在多数据源的情况下，传统的@Transactional注解可能无法很好地满足分布式事务的需求。此时，可以使用@DSTransactional注解（可能是基于某些框架，如 Apache ShardingSphere 提供的注解）来代替@Transactional注解，它可以更好地处理多数据源的事务一致性问题，避免数据源切换时的事务失效。

以使用 ShardingSphere 框架为例，实现步骤如下：

添加依赖：需确保依赖兼容 Spring Boot 3（基于 Jakarta EE 9+），在pom.xml文件中添加如下依赖：

配置数据源与事务管理器：在application.yml中配置多数据源，例如：

使用@DSTransactional注解：在 Service 层方法上添加注解，假设@ShardingSphereTransactionType等效于@DSTransactional：

同时，在使用过程中要注意事务模式的选择，根据场景选择 XA、Saga 或 Base（AT）模式。XA 适合强一致性场景，AT 适合高性能场景。确保方法抛出RuntimeException以触发回滚，避免try - catch吞没异常。合理配置事务超时时间，防止长时间锁定，例如：

事务隔离级别决定了一个事务对其他并发事务的可见性和影响程度。在 Spring Boot 中，通过设置@Transactional注解的isolation属性来配置事务隔离级别。常见的事务隔离级别有：

Isolation.DEFAULT：使用数据库默认的隔离级别。不同的数据库默认隔离级别可能不同，例如 MySQL 的默认隔离级别是REPEATABLE_READ，而 Oracle 的默认隔离级别是READ_COMMITTED。

Isolation.READ_UNCOMMITTED：最低的隔离级别，允许一个事务读取另一个未提交事务修改的数据。这种隔离级别可能会导致脏读、不可重复读和幻读等问题，但在某些对数据一致性要求不高，追求高并发性能的场景下可以使用。

Isolation.READ_COMMITTED：一个事务只能读取已经提交的其他事务修改的数据，避免了脏读问题。但在同一事务中多次读取同一数据时，可能会因为其他事务的修改而导致读取结果不一致，即不可重复读问题。

Isolation.REPEATABLE_READ：在同一事务中多次读取同一数据时，读取结果保持一致，即使其他事务在期间对该数据进行了修改并提交。它避免了脏读和不可重复读问题，但可能会出现幻读问题，即当一个事务在查询某一范围的数据时，另一个事务在该范围内插入了新的数据，导致前一个事务再次查询时得到了不同的结果。

Isolation.SERIALIZABLE：最高的隔离级别，它通过强制事务串行执行，避免了脏读、不可重复读和幻读等所有并发问题。但由于所有事务都需要排队执行，会严重影响系统的并发性能。

在实际项目中，需要根据业务需求和并发控制要求，谨慎选择合适的事务隔离级别。例如，如果业务对数据一致性要求非常高，且并发访问量不大，可以选择Isolation.SERIALIZABLE隔离级别；如果业务对并发性能要求较高，而对数据一致性的一些小问题可以容忍，可以选择Isolation.READ_COMMITTED或Isolation.REPEATABLE_READ隔离级别。

尽量保持事务边界小而简单，这是避免事务冲突的一个重要原则。事务边界就像是一个包围圈，包围的范围越大，里面的操作就越多，出现冲突的可能性也就越大。因此，要避免在事务中进行复杂的计算或耗时的操作，比如网络请求、文件读写等。

以一个电商系统为例，在处理订单的事务中，只应该包含与订单数据更新、库存扣减等直接相关的数据库操作，而不应该在事务中进行复杂的运费计算或者调用第三方物流接口获取物流信息等耗时操作。可以将这些操作放在事务之外，或者在事务提交后异步执行。这样可以减少事务执行期间的锁竞争和资源占用，降低分布式事务和本地事务冲突的可能性。同时，小而简单的事务边界也更容易理解和维护，当出现问题时，排查和调试也会更加方便。

在 Spring Boot3 开发中，避免分布式事务和本地事务冲突是保障系统数据一致性和稳定性的关键。通过深入理解分布式事务和本地事务的原理、冲突产生的原因，采用如引入 Seata 框架、合理设置事务传播机制和隔离级别、使用适合多数据源的注解以及保持事务边界简单等策略，开发者能够有效地应对这一挑战。在实际项目中，需要根据业务场景的特点，综合运用这些方法，精心配置和管理事务，确保分布式系统的高效运行和数据的准确可靠。希望本文的内容能够为广大互联网软件开发人员在处理相关问题时提供有益的参考和帮助，让我们在 Spring Boot3 的开发道路上更加顺畅地前行。

来源：从程序员到架构师