Spring Batch 5.2.0 正式发布！

版本发布 | Mahmoud Ben Hassine | 2024年11月20日 | ...

我谨代表团队和所有贡献者，很高兴地宣布 Spring Batch 5.2 正式版已从 Maven Central 提供。这篇博文将带您了解本次发布的主要新增功能。完整的变更列表，请参阅发布说明。

主要亮点

本次发布的主要亮点包括：

依赖升级
MongoDB 作业仓库支持
新的无资源作业仓库
组合式项目读取器实现
针对 java.util.function API 的新适配器
支持带有阻塞队列项目读取器和写入器的并发步骤
JPA 项目读取器中的查询提示支持
JDBC 项目读取器中的数据类支持
作业注册改进

依赖升级

在此版本中，Spring 依赖项已升级到以下版本：

Spring Framework：6.2.0
Spring Integration：6.4.0
Spring Data：3.4.0
Spring Kafka：3.3.0
Spring AMQP：3.2.0
Spring Retry：2.0.10
Spring Ldap：3.2.8
Micrometer：1.14.1

MongoDB 作业仓库支持

此版本引入了第一个由 MongoDB 支持的 NoSQL 作业仓库实现。与关系型作业仓库实现类似，Spring Batch 提供了一个脚本来在 MongoDB 中创建必要的集合，以便保存和检索批处理元数据。

此实现需要 MongoDB 4 或更高版本，并基于 Spring Data MongoDB。要使用此作业仓库，您只需定义一个 `MongoTemplate` 和一个 `MongoTransactionManager`，它们是新添加的 `MongoDBJobRepositoryFactoryBean` 所必需的。

@Bean
public JobRepository jobRepository(MongoTemplate mongoTemplate, MongoTransactionManager transactionManager) throws Exception {
	MongoJobRepositoryFactoryBean jobRepositoryFactoryBean = new MongoJobRepositoryFactoryBean();
	jobRepositoryFactoryBean.setMongoOperations(mongoTemplate);
	jobRepositoryFactoryBean.setTransactionManager(transactionManager);
	jobRepositoryFactoryBean.afterPropertiesSet();
	return jobRepositoryFactoryBean.getObject();
}

一旦定义了 MongoDB 作业仓库，您就可以像普通作业仓库一样将其注入到任何作业或步骤中。您可以在 MongoDBJobRepositoryIntegrationTests 中找到完整的示例。

新的无资源作业仓库

在 v5 中，出于多种原因，内存中的基于 Map 的作业仓库实现已被移除。Spring Batch 中唯一剩余的作业仓库实现是 JDBC 实现，它需要一个数据源。虽然这对于 H2 或 HSQLDB 等内存数据库效果很好，但要求提供数据源对于我们社区中许多用户来说是一个强烈的限制，他们过去习惯于在没有额外依赖的情况下使用基于 Map 的仓库。

在此版本中，我们引入了一个 `JobRepository` 实现，它不使用或存储任何形式的批处理元数据（甚至不存储在内存中）。这是一个“NoOp”实现，它会丢弃批处理元数据，并且不与任何资源交互（因此得名“无资源作业仓库”，与“无资源事务管理器”同名）。

此实现适用于**不**需要可重用性，并且**不**涉及任何执行上下文用例（例如，通过执行上下文在步骤之间共享数据，或在管理器和工作程序之间通过执行上下文共享分区元数据的分区步骤等）。

此实现适用于在自己的 JVM 中执行的一次性作业。它既可以与事务性步骤（例如，配置了 `DataSourceTransactionManager`）一起使用，也可以与非事务性步骤（配置了 `ResourcelessTransactionManager`）一起使用。此实现**不**是线程安全的，**不**应在任何并发环境中使用。

组合式项目读取器实现

与 `CompositeItemProcessor` 和 `CompositeItemWriter` 类似，我们引入了一个新的 `CompositeItemReader` 实现，它旨在从具有相同格式的多个源顺序读取数据。这在数据分布在不同资源中且编写自定义读取器不可行时非常有用。

`CompositeItemReader` 的工作方式与其他组合件类似，按顺序将读取操作委托给常规项目读取器。下面是一个快速示例，展示了一个组合读取器，它从平面文件然后从关系数据库表中读取人员数据。

@Bean
public FlatFileItemReader<Person> itemReader1() {
    return new FlatFileItemReaderBuilder<Person>()
            .name("personFileItemReader")
            .resource(new FileSystemResource("persons.csv"))
            .delimited()
            .names("id", "name")
            .targetType(Person.class)
            .build();
}

@Bean
public JdbcCursorItemReader<Person> itemReader2() {
    String sql = "select * from persons";
    return new JdbcCursorItemReaderBuilder<Person>()
            .name("personTableItemReader")
            .dataSource(dataSource())
            .sql(sql)
            .beanRowMapper(Person.class)
            .build();
}

@Bean
public CompositeItemReader<Person> itemReader() {
    return new CompositeItemReader<>(Arrays.asList(itemReader1(), itemReader2()));
}

针对 java.util.function API 的新适配器

与适配 `java.util.function.Function` 为项目处理器的 `FucntionItemProcessor` 类似，此版本为其他 `java.util.function` 接口（如 `Supplier`、`Consumer` 和 `Predicate`）引入了几个新适配器。

新添加的适配器是：`SupplierItemReader`、`ConsumerItemWriter` 和 `PredicateFilteringItemProcessor`。有关这些新适配器的更多详细信息，请参阅 `org.springframework.batch.item.function` 包。

支持带有阻塞队列项目读取器和写入器的并发步骤

阶段事件驱动架构 (SEDA) 是一种强大的架构风格，用于通过队列连接的阶段处理数据。这种风格直接适用于数据管道，并且由于可以将作业设计为一系列步骤，因此在 Spring Batch 中易于实现。

这里唯一缺失的是如何读取和写入数据到中间队列。此版本引入了一个项目读取器和项目写入器，用于从 `BlockingQueue` 读取数据并写入到其中。借助这两个新类，可以设计一个准备队列中数据的第一个步骤和一个从同一队列消费数据的第二个步骤。这样，两个步骤就可以并发运行，以非阻塞、事件驱动的方式高效处理数据。

JPA 项目读取器中的查询提示支持

直到 5.1 版本，JPA Cursors 和 Paging 项目读取器都不支持查询提示（例如，fetch size、timeout 等）。用户需要提供自定义查询提供程序才能指定自定义提示。

在此版本中，JPA 读取器及其相应的构建器已更新，以便在定义要使用的 JPA 查询时接受查询提示。

JDBC 项目读取器中的数据类支持

此版本在 JDBC Cursor 和 Paging 项目读取器的构建器中引入了一个新方法，该方法允许用户在项目类型为数据类（Java 记录或 Kotlin 数据类）时指定 `DataClassRowMapper`。

新方法名为 `dataRowMapper(TargetType.class)`，与 `beanRowMapper(TargetType.class)` 类似，旨在使常规类（Java Bean）和数据类（Java 记录）之间的行映射器配置保持一致。

作业注册改进

在 5.1 版本中，批处理基础设施 Bean 的默认配置已更新，通过在应用程序上下文中定义 `JobRegistryBeanPostProcessor` Bean 来自动填充作业注册表。在 Spring Framework 最近一次更新中，`BeanPostProcessorChecker` 的日志级别发生了变化，导致在一个典型的 Spring Batch 应用程序中记录了许多与 `JobRegistryBeanPostProcessor` 相关的警告。这些警告是由于 `JobRegistryBeanPostProcessor` Bean 依赖于 `JobRegistry` Bean，这是不推荐的做法，并且可能导致 Bean 生命周期问题。

这些问题已在此版本中得到解决，方法是将填充 `JobRegistry` 的机制从使用 `BeanPostProcessor` 更改为使用 `SmartInitializingSingleton`。现在，`JobRegistryBeanPostProcessor` 已被弃用，取而代之的是新添加的 `JobRegistrySmartInitializingSingleton`。

下一步是什么？

首先，我要感谢所有为本次发布做出贡献的贡献者！对于 Spring Boot 用户，Spring Batch 5.2 可通过 Spring Boot 3.4 获得。

我们期待您在 Github Issues、Github Discussions、Twitter 和 StackOverflow 上提供反馈。

注意： Spring Batch 5.1.x 将于 2024 年 11 月 22 日停止 OSS 支持。因此，我鼓励我们的用户尽快将他们的应用程序升级到 Spring Batch 5.2.0。

Spring Batch 主页|Github 上的源代码|参考文档

Spring 博客