介绍
在本文中，我将向您展示各种 Spring Transaction 最佳实践，它们可以帮助您实现底层业务需求所需的数据完整性保证。
数据完整性至关重要，因为如果没有适当的事务处理，您的应用程序可能容易受到可能对底层业务产生可怕后果的[竞争条件的影响。]
模拟 Flexcoin 竞争条件
在[本文中]，我解释了 Flexcoin 是如何因为竞争条件而破产的，一些黑客利用这种竞争条件窃取了 Flexcoin 可用的所有 BTC 资金。
我们之前的实现是使用纯 JDBC 构建的，但我们可以使用 Spring 模拟相同的场景，这对于绝大多数 Java 开发人员来说肯定更熟悉。这样，我们将使用现实生活中的问题作为示例，说明在构建基于 Spring 的应用程序时应该如何处理事务。
因此，我们将使用以下服务层和数据访问层组件来实现我们的传输服务：
image.png
为了演示当事务没有根据业务需求处理时会发生什么，让我们使用最简单的数据访问层实现：
@Repository
@Transactional(readOnly = true)
public interface AccountRepository extends JpaRepository<Account, Long> {
@Query(value = """
SELECT balance
FROM account
WHERE iban = :iban
""",
nativeQuery = true)
long getBalance(@Param("iban") String iban);
@Query(value = """
UPDATE account
SET balance = balance + :cents
WHERE iban = :iban
""",
nativeQuery = true)
@Modifying
@Transactional
int addBalance(@Param("iban") String iban, @Param("cents") long cents);
}
getBalance和方法都addBalance使用 Spring@Query注释来定义可以读取或写入给定帐户余额的本机 SQL 查询。
因为读操作多于写操作，所以
@Transactional(readOnly = true)在每个类级别上定义注释是一种很好的做法。这样，默认情况下，没有注释的方法
@Transactional将在只读事务的上下文中执行，除非现有的读写事务已经与当前处理的执行线程相关联。但是，当我们想改变数据库状态时，我们可以使用
@Transactional注解来标记读写事务方法，并且，如果没有事务已经启动并传播到该方法调用，那么读写事务上下文将是为此方法执行创建。有关
@Transactional注释的更多详细信息，也请查看这篇文章。
妥协的原子性
AfromACID代表原子性，它允许事务将数据库从一个一致状态移动到另一个一致状态。因此，原子性允许我们在同一个数据库事务的上下文中注册多个语句。
在 Spring 中，这可以通过@Transactional注解来实现，所有应该与关系数据库交互的公共服务层方法都应该使用注解。
如果您忘记这样做，则业务方法可能会跨越多个数据库事务，从而损害原子性。
例如，假设我们实现了transfer这样的方法：
@Service
public class TransferServiceImpl implements TransferService {
@Autowired
private AccountRepository accountRepository;
@Override
public boolean transfer(
String fromIban, String toIban, long cents) {
boolean status = true;
long fromBalance = accountRepository.getBalance(fromIban);
if(fromBalance >= cents) {
status &= accountRepository.addBalance(
fromIban, (-1) * cents
) > 0;
status &= accountRepository.addBalance(
toIban, cents
) > 0;
}
return status;
}
}
考虑到我们有两个用户，Alice 和 Bob：
| iban | balance | owner |
|-----------|---------|-------|
| Alice-123 | 10 | Alice |
| Bob-456 | 0 | Bob |
运行并行执行测试用例时：
@Test
public void testParallelExecution()
throws InterruptedException {
assertEquals(10L, accountRepository.getBalance("Alice-123"));
assertEquals(0L, accountRepository.getBalance("Bob-456"));
CountDownLatch startLatch = new CountDownLatch(1);
CountDownLatch endLatch = new CountDownLatch(threadCount);
for (int i = 0; i < threadCount; i++) {
new Thread(() -> {
try {
startLatch.await();
transferService.transfer(
"Alice-123", "Bob-456", 5L
);
} catch (Exception e) {
LOGGER.error("Transfer failed", e);
} finally {
endLatch.countDown();
}
}).start();
}
startLatch.countDown();
endLatch.await();
LOGGER.info(
"Alice's balance {}",
accountRepository.getBalance("Alice-123")
);
LOGGER.info(
"Bob's balance {}",
accountRepository.getBalance("Bob-456")
);
}
我们将获得以下账户余额日志条目：
Alice's balance: -5
Bob's balance: 15
所以，我们有麻烦了！鲍勃设法获得了比爱丽丝最初在她帐户中的更多的钱。
我们得到这个竞争条件的原因是该transfer方法不是在单个数据库事务的上下文中执行的。
由于我们忘记添加@Transactional该transfer方法，Spring 不会在调用此方法之前启动事务上下文，因此，我们最终将运行三个连续的数据库事务：
* 一个用于`getBalance`选择 Alice 帐户余额的方法调用
* `addBalance`用于从爱丽丝账户中扣款的第一个电话
* 另一个用于第二次`addBalance`通话，记入 Bob 的帐户
方法之所以以AccountRepository事务方式执行是由于@Transactional我们添加到类和addBalance方法定义中的注释。
服务层的主要目标是定义给定工作单元的事务边界。
如果服务要调用多个
Repository方法，那么拥有跨越整个工作单元的单个事务上下文非常重要。
依赖交易默认值
@Transactional因此，让我们通过向方法添加注释来解决第一个问题transfer：
@Transactional
public boolean transfer(
String fromIban, String toIban, long cents) {
boolean status = true;
long fromBalance = accountRepository.getBalance(fromIban);
if(fromBalance >= cents) {
status &= accountRepository.addBalance(
fromIban, (-1) * cents
) > 0;
status &= accountRepository.addBalance(
toIban, cents
) > 0;
}
return status;
}
现在，当重新运行testParallelExecution测试用例时，我们将得到以下结果：
Alice's balance: -50
Bob's balance: 60
因此，即使读取和写入操作是原子完成的，问题也没有得到解决。
我们这里的问题是由丢失更新异常引起的，Oracle、SQL Server、PostgreSQL 或 MySQL 的默认隔离级别无法阻止该异常：
image.png
虽然多个并发用户可以读取账户余额5，但只有第一个用户UPDATE会将余额从 更改5为0。第二个UPDATE会认为账户余额是它之前读取的余额，而实际上，余额已经被另一笔成功提交的交易改变了。
为了防止丢失更新异常，我们可以尝试多种解决方案：
- 我们可以使用乐观锁定，如[本文所述]
- 我们可以通过使用
FOR UPDATE指令锁定 Alice 的帐户记录来使用悲观锁定方法，如[本文所述] - 我们可以使用更严格的隔离级别
根据底层关系数据库系统，这就是如何使用更高的隔离级别来防止丢失更新异常：
| Isolation Level | Oracle | SQL Server | PostgreSQL | MySQL |
|-----------------|--------|------------|------------|-------|
| Read Committed | Yes | Yes | Yes | Yes |
| Repeatable Read | N/A | No | No | Yes |
| Serializable | No | No | No | No |
由于我们在 Spring 示例中使用 PostgreSQL，让我们将隔离级别从默认值更改Read Committed为Repeatable Read.
正如我在本文@Transactional中所解释的，您可以在注释级别设置隔离级别：
@Transactional(isolation = Isolation.REPEATABLE_READ)
public boolean transfer(
String fromIban, String toIban, long cents) {
boolean status = true;
long fromBalance = accountRepository.getBalance(fromIban);
if(fromBalance >= cents) {
status &= accountRepository.addBalance(
fromIban, (-1) * cents
) > 0;
status &= accountRepository.addBalance(
toIban, cents
) > 0;
}
return status;
}
而且，在运行testParallelExecution集成测试时，我们将看到丢失更新异常将被阻止：
Alice's balance: 0
Bob's balance: 10
仅仅因为默认隔离级别在许多情况下都很好，并不意味着您应该将其专门用于任何可能的用例。
如果给定的业务用例需要严格的数据完整性保证，那么您可以使用更高的隔离级别或更精细的并发控制策略，例如乐观锁定机制。
Spring @Transactional 注解背后的魔力
transfer从testParallelExecution集成测试调用方法时，堆栈跟踪如下所示：
"Thread-2"@8,005 in group "main": RUNNING
transfer:23, TransferServiceImpl
invoke0:-1, NativeMethodAccessorImpl
invoke:77, NativeMethodAccessorImpl
invoke:43, DelegatingMethodAccessorImpl
invoke:568, Method {java.lang.reflect}
invokeJoinpointUsingReflection:344, AopUtils
invokeJoinpoint:198, ReflectiveMethodInvocation
proceed:163, ReflectiveMethodInvocation
proceedWithInvocation:123, TransactionInterceptor$1
invokeWithinTransaction:388, TransactionAspectSupport
invoke:119, TransactionInterceptor
proceed:186, ReflectiveMethodInvocation
invoke:215, JdkDynamicAopProxy
transfer:-1, $Proxy82 {jdk.proxy2}
lambda$testParallelExecution$1:121
在transfer调用方法之前，有一个 AOP（面向方面的编程）方面会被执行，对我们来说最重要的是TransactionInterceptor扩展TransactionAspectSupport类：
image.png
虽然这个 Spring Aspect 的入口点是 . TransactionInterceptor，但最重要的操作发生在它的基类TransactionAspectSupport.
例如，这是 Spring 处理事务上下文的方式：
protected Object invokeWithinTransaction(
Method method,
@Nullable Class<?> targetClass,
final InvocationCallback invocation) throws Throwable {
TransactionAttributeSource tas = getTransactionAttributeSource();
final TransactionAttribute txAttr = tas != null ?
tas.getTransactionAttribute(method, targetClass) :
null;
final TransactionManager tm = determineTransactionManager(txAttr);
...
PlatformTransactionManager ptm = asPlatformTransactionManager(tm);
final String joinpointIdentification = methodIdentification(
method,
targetClass,
txAttr
);
TransactionInfo txInfo = createTransactionIfNecessary(
ptm,
txAttr,
joinpointIdentification
);
Object retVal;
try {
retVal = invocation.proceedWithInvocation();
}
catch (Throwable ex) {
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
cleanupTransactionInfo(txInfo);
}
commitTransactionAfterReturning(txInfo);
...
return retVal;
}
服务方法调用由invokeWithinTransaction启动新事务上下文的方法包装，除非已经启动并传播到此事务方法。
如果RuntimeException抛出 a，则事务回滚。否则，如果一切顺利，则提交事务。
结论
在开发一个重要的应用程序时，了解 Spring 事务的工作方式非常重要。首先，您需要确保围绕逻辑工作单元正确声明事务边界。
其次，您必须知道何时使用默认隔离级别以及何时使用更高的隔离级别。
根据该标志，您甚至可以将事务路由到连接到副本节点的read-only只读节点，而不是[主节点]
网友评论