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 部落格