Spring JPA：saveandflush 与 save 的成本是多少？

Question

我有一个由一组微服务构建的应用程序。一项服务接收数据，通过 Spring JPA 和 Eclipse link 持久化数据，然后向第二项服务发送警报 (AMQP)。

根据特定条件，第二个服务然后针对持久化数据调用 RESTfull Web 服务以检索保存的信息。

我注意到有时 RESTfull 服务 returns 一个空数据集，即使之前已经保存了数据。查看持久服务的代码，使用了 save 而不是 saveandflush 所以我假设数据没有足够快地刷新下游查询服务。

saveandflush 是否有我应该厌倦的成本，或者默认使用它是否合理？
它会确保下游应用程序的数据可用性的即时性吗？

应该说原来的持久化函数是包裹在@Transactional

Answer 1

问题的可能预测

我认为这里的问题与 save 和 saveAndFlush 无关。该问题似乎与 Spring @Transactional 方法的性质有关，并且在涉及您的数据库和 AMQP 代理的分布式环境中错误地使用了这些事务，并且可能添加到该有毒组合中，对 JPA 上下文如何工作的一些基本误解。

在您的解释中，您似乎暗示您在 @Transactional 方法中启动 JPA 事务，并且在事务期间（但在提交之前），您将消息发送到 AMQP 代理。稍后，在队列的另一端，消费者应用程序获取消息并进行 REST 服务调用。此时，您注意到发布方的事务更改尚未提交到数据库，因此对消费者方不可见。

问题似乎是您在 JPA 事务提交到磁盘之前传播了这些 AMQP 消息。当消费者阅读一条消息并对其进行处理时，您与发布方的交易可能尚未完成。因此，这些更改对消费者应用程序不可见。

如果您的 AMPQ 实现是 Rabbit，那么我以前见过这个问题。当您启动使用数据库事务管理器的 @Transactional 方法时，并在该方法内使用 RabbitTemplate 发送相应的消息。

如果您的 RabbitTemplate 没有使用事务通道（即 channelTransacted=true），那么您的消息会在数据库事务提交之前传送。我相信通过在您的 RabbitTemplate 中启用交易渠道（默认情况下禁用），您可以解决部分问题。

<rabbit:template id="rabbitTemplate" 
                 connection-factory="connectionFactory" 
                 channel-transacted="true"/>

当通道被处理时，RabbitTemplate“加入”当前数据库事务（这显然是一个 JPA 事务）。一旦您的 JPA 事务提交，它运行一些尾声代码也会提交您的 Rabbit 通道中的更改，这会强制实际“发送”消息。

关于保存与 saveAndFlush

您可能认为刷新 JPA 上下文中的更改应该可以解决问题，但您错了。刷新 JPA 上下文只会强制将实体中的更改（此时仅在内存中）写入磁盘。但是，它们仍然会在相应的数据库事务中写入磁盘，在您的 JPA 事务提交之前不会提交。这发生在您的 @Transactional 方法的末尾（不幸的是，在您已经发送 AMQP 消息后的某个时间 — 如果您不使用如上所述的交易通道）。

因此，即使您刷新 JPA 上下文，您的消费者应用程序也不会看到这些更改（根据经典数据库隔离级别规则），直到您的 @Transactional 方法在您的发布者应用程序中完成。

当您调用 save(entity), 时，EntityManager 不需要立即同步任何更改。大多数 JPA 实现只是在内存中将实体标记为脏，并等到最后一刻将所有更改与数据库同步并在数据库级别提交这些更改。

注意：在某些情况下，您可能希望其中一些更改立即写入磁盘，而不是直到异想天开的 EntityManager 决定这样做。一个典型的例子是数据库 table 中有一个触发器，您需要它运行生成一些您稍后在交易过程中需要的额外记录。因此，您强制将更改刷新到磁盘，以便触发器被强制为运行.

通过刷新上下文，您只是强制将内存中的更改同步到磁盘，但这并不意味着这些修改会立即提交到数据库中。因此，您刷新的那些更改不一定对其他交易可见。基于传统的数据库隔离级别，它们很可能不会。

2PC 问题

这里的另一个经典问题是您的数据库和您的 AMQP 代理是两个独立的系统。如果这是关于 Rabbit 的，那么你没有 2PC（两阶段提交）。

因此您可能想要考虑一些有趣的场景，例如，您的数据库事务成功提交。尽管如此，Rabbit 仍无法提交您的消息，在这种情况下，您将不得不重复整个事务，可能会跳过数据库副作用，只是重新尝试将消息发送给 Rabbit。

您可能应该阅读 Distributed transactions in Spring, with and without XA 上的这篇文章，特别是关于链交易的部分有助于解决这个问题。

他们建议使用更复杂的事务管理器定义。例如：

<bean id="jdbcTransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>

<bean id="rabbitTransactionManager" class="org.springframework.amqp.rabbit.transaction.RabbitTransactionManager">
    <property name="connectionFactory" ref="connectionFactory"/>
</bean>

<bean id="chainedTransactionManager" class="org.springframework.data.transaction.ChainedTransactionManager">
    <constructor-arg name="transactionManagers">
        <array>
            <ref bean="rabbitTransactionManager"/>
            <ref bean="jdbcTransactionManager"/>
        </array>
    </constructor-arg>
</bean>

然后，在您的代码中，您只需使用链式事务管理器来协调您的数据库事务部分和 Rabbit 事务部分。

现在，您仍有可能提交数据库部分，但 Rabbit 事务部分失败。

所以，想象一下这样的事情：

@Retry
@Transactional("chainedTransactionManager")
public void myServiceOperation() {
    if(workNotDone()) {
        doDatabaseTransactionWork();
    }
    sendMessagesToRabbit();
}

以这种方式，如果您的 Rabbit 事务部分因任何原因失败，并且您被迫重试整个链式事务，您将避免重复数据库副作用，只需确保将失败的消息发送给 Rabbit。

同时，如果您的数据库部分出现故障，那么您从未将消息发送给 Rabbit，也不会有任何问题。

或者，如果您的数据库副作用是幂等的，那么您可以跳过检查，只需重新应用数据库更改，然后重新尝试将消息发送到 Rabbit。

事实是，最初，您尝试做的事情看似简单，但一旦您深入研究不同的问题并理解它们，您就会意识到以正确的方式做到这一点是一件棘手的事情。

Spring JPA：saveandflush 与 save 的成本是多少？

Spring JPA: What is the cost of saveandflush vs save?

java

spring

eclipselink

spring-data-jpa