在春季批处理作业上重新定义数据库“事务”边界

Question

有没有办法在春季批处理作业上重新定义数据库“事务”边界？

上下文：

我们有一个简单的支付处理作业，它读取 x 条支付记录，处理并将数据库中的记录标记为已处理。目前，作者执行 REST API 调用（到支付网关），处理 API 响应并将记录标记为已处理。我们正在采用面向块的方法，因此在整个块完成之前，更新不会刷新到数据库中。因为，基本上整个读/写都在一个事务中，我们开始看到过多的数据库锁和争用。例如，如果 API 需要很长时间来响应（比如 30 秒），整个应用程序就会开始受到影响。

我们显然可以将 API 调用的超时时间减少到一个更小的值。但这仍然不能解决表可能被锁定的时间超过预期持续时间的问题。理想情况下，我们希望使数据库事务尽可能短。我们的想法是，如果这项工作的“内容”可以在数据库事务之外完成，我们就可以绕过这个问题。因此，如果 API 调用发生在数据库事务之外……我们可以承受它多花几秒钟的时间来接受响应，而不是导致/增加长锁定持续时间。

这是正确的方法吗？如果不是，以春季批处理方式处理这项“简单”工作的推荐方法是什么？还有其他更适合该任务的批处理工具吗？ （如果 spring-batch 不是正确的选择）。

如果需要，可以提供更多上下文。

Answer 1

我没有对您所有问题的准确答案，但我会尽力提供一些指导。

由于基本上整个读/写都在一个事务中，我们开始看到过多的数据库锁和争用。例如，如果 API 需要很长时间来响应（比如 30 秒），整个应用程序就会开始受到影响。

自诞生之日起，术语批处理或“以“批次”处理数据是基于将一批记录视为一个单元的想法：要么处理所有记录（无论“过程”一词是什么意思），要么不处理的记录被处理。这种“全有或全无”语义正是 Spring Batch 在其面向块的处理模型中实现的。实现这样一个（强大的）属性需要权衡取舍。在您的情况下，您需要在一致性和响应性之间进行权衡。

我们显然可以将 API 调用的超时时间减少到一个更小的值。但这仍然不能解决表可能被锁定的时间超过预期持续时间的问题。

块大小是对交易行为影响最大的参数。您可以做的是尝试减少单个事务中要处理的记录数并查看结果。没有最佳值，这是一个经验过程。这还取决于您在处理块期间调用的 API 的响应能力。

我们的想法是，如果这项工作的“内容”可以在数据库事务之外完成，我们就可以绕过这个问题。因此，如果 API 调用发生在数据库事务之外……我们可以承受它多花几秒钟的时间来接受响应，而不是导致/增加长锁定持续时间。

避免在实时系统上进行此类更新的常用技术是将处理卸载到另一个数据存储，然后在单个事务中复制更新。这个想法是用给定的批处理 id 标记记录，并将这些记录复制到批处理过程可以在不影响实时数据存储的情况下使用的不同数据存储（甚至是同一数据存储中的临时表）。一旦处理完成（可以并行完成以提高性能），记录可以在单个事务中的实时系统中标记为已处理（这通常非常快，并且可以基于批处理 id 来识别哪些记录更新）。