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

Question

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

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

我注意到有时 RESTfull 服务会返回空数据集，即使数据之前已保存。查看持久化服务的代码，使用了 save 而不是 saveandflush，所以我假设数据刷新的速度不够快以供下游服务查询。

saveandflush 是否有我应该厌倦的成本，或者默认使用它是否合理？

它会确保数据对下游应用程序的即时可用性吗？

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

Answer 1

问题的可能预测
我相信这里的问题与save无关。对比 saveAndFlush .问题似乎与 Spring 的性质有关 @Transactional方法，以及在涉及您的数据库和 AMQP 代理的分布式环境中错误使用这些事务，并且可能会增加对 JPA 上下文如何工作的一些基本误解。
在您的解释中，您似乎暗示您在 @Transactional 内开始您的 JPA 事务。方法，并且在事务期间(但在提交之前)，您将消息发送到 AMQP 代理。稍后，在队列的另一端，消费者应用程序获取消息并进行 REST 服务调用。此时，您注意到来自发布方的事务性更改尚未提交到数据库，因此对消费者方不可见。
问题似乎是您在 JPA 事务中传播这些 AMQP 消息，然后才将其提交到磁盘。当消费者读取消息并对其进行处理时，您从发布方的交易可能尚未完成。因此，消费者应用程序看不到这些更改。
如果你的 AMPQ 实现是 Rabbit，那么我之前也见过这个问题。当您开始 @Transactional使用数据库事务管理器的方法，在该方法中，您使用 RabbitTemplate发送相应的消息。
如果您的 RabbitTemplate未使用事务 channel (即 channelTransacted=true )，那么您的消息将在数据库事务提交之前传递。我相信通过在您的 RabbitTemplate 中启用交易 channel (默认情况下禁用) ，你解决了部分问题。

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

当 channel 被交易时，则 RabbitTemplate “加入”当前的数据库事务(显然是一个 JPA 事务)。一旦您的 JPA 事务提交，它就会运行一些尾声代码，这些代码也会提交您的 Rabbit channel 中的更改，这会强制实际“发送”消息。
关于 save 与 saveAndFlush
您可能认为刷新 JPA 上下文中的更改应该可以解决问题，但您错了。刷新 JPA 上下文只会强制将实体中的更改(此时仅在内存中)写入磁盘。但是，它们仍然在相应的数据库事务中写入磁盘，直到您的 JPA 事务提交后才会提交。这发生在您的 @Transactional 的末尾方法(不幸的是，在您已经发送了 AMQP 消息之后的一段时间 - 如果您不使用如上所述的事务处理 channel )。
因此，即使您刷新 JPA 上下文，您的消费者应用程序也不会看到这些更改(根据经典数据库隔离级别规则)，直到您 @Transactional方法已在您的发布者应用程序中完成。
当您调用 save(entity), EntityManager不需要立即同步任何更改。大多数 JPA 实现只是将实体标记为内存中的脏，并等到最后一分钟将所有更改与数据库同步并在数据库级别提交这些更改。
注意:在某些情况下，您可能希望其中一些更改立即下放到磁盘，直到异想天开的 EntityManager决定这样做。当数据库表中有一个触发器需要它运行以生成一些您稍后在事务期间需要的附加记录时，就会发生这种情况的一个经典示例。因此，您强制将更改刷新到磁盘，从而强制运行触发器。
通过刷新上下文，您只是强制将内存中的更改同步到磁盘，但这并不意味着这些修改的即时数据库提交。因此，您刷新的那些更改不一定对其他事务可见。基于传统的数据库隔离级别，它们很可能不会。
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。
事实是，最初，您尝试做的事情看似简单，但是一旦您深入研究了不同的问题并理解了它们，您就会意识到以正确的方式做这件事是一件棘手的事情。