使用步骤决定器和块时的弹簧批处理

Question

我开始使用 Spring Batch，我有一个关于何时使用步骤、决定器和块的问题。

给定以下输入：

<UserAuthorizationEvent>
    <UserAuthorization>
        <Action>ADD</Action>
        <UserName>Name1</UserName>
        <!-- more properties here -->
    </UserAuthorization>
    <UserAuthorization>
        <Action>UPDATE</Action>
        <UserId>456</UserId>
        <UserName>NewName2</UserName>
        <!-- more properties here -->
    </UserAuthorization>
    <UserAuthorization>
        <UserId>789</UserId>
        <Action>DELETE</Action>
    </UserAuthorization>
    <!-- 1000 or more UserAuthorization here -->
</UserAuthorizationEvent>

对于文件中的每个<UserAuthorization>，我将根据<Action> 在数据库上执行查询之前验证不同的业务规则。 （例如：对于 ADD，验证 UserName 在数据库中是唯一的，并且它只由字母组成，或者对于 DELETE，验证 id 是否存在于表中）

然后<Action> 值将决定我是否需要在数据库中插入、更新或删除一个值。 （操作可以有其他值，例如 UPDATE_RIGHTS 或 RESET_PASSWORD）

什么是最好的？

我是否定义了这样的工作：

<job id="myJob" xmlns="http://www.springframework.org/schema/batch">
    <step id="step1">
        <tasklet>
            <chunk reader="itemReader" processor="itemProcessor" writer="itemWriter" commit-interval="2" />
        </tasklet>
    </step>
</job>

• itemReader 将读取 xml 文件并一次返回一个 <UserAuthorization>。
• itemProcessor 将充满ifs 以根据其<Action> 值验证当前项目的业务规则
• itemWriter 会将项目保存在数据库中。如果我想在执行查询之前执行更多操作，是否也需要在此处添加逻辑？

这样做，我担心我没有正确使用 Spring 批处理。

这样做对吗？

我可以使用几个步骤和决策器来实现批处理的所有逻辑吗？ 你有例子吗？

Answer 1

对此类问题使用 SB 是正确的决定，您只需要一个步骤（对于此用例）。

第一个解决方案：
阅读器是微不足道的（使用StaxEventItemReader），处理器是无用的（除非您需要执行一些业务检查）。
更有趣的一点是作者，因为你必须：

1. 为执行实际写入逻辑的每个操作（例如AddItemWriter, UpdateItemWriter, DeleteItemWriter）定义一个自定义写入器
2. 创建一个主写入器（由专用写入器组成），您可以在其中根据<ACTION> 标记值将写入分配给正确的写入器。

第二种解决方案（可能有点“复杂”）：

1. 标准StaxEventItemReader
2. 自定义ItemProcessor从<UserAuthorization>转换为自定义Action类封装操作（例如AddUserAuth, DeleteUserAuth, UpdateUserAuth）
3. 为执行实际写入逻辑的每个操作（例如AddItemWriter, UpdateItemWriter, DeleteItemWriter）定义一个自定义写入器
4. 作为主要作者使用基于SubclassClassifier 的ClassifierCompositeItemWriter；此分类器使用从处理器创建的自定义 Action 类分派给正确的编写者

此解决方案比解决方案更（容易）可扩展，因为您只需要为（新）操作创建自定义 Action 类 - 和正确的编写器，而编写只是一个配置问题。

Answer 2

Spring Batch 在这里看起来有点矫枉过正。但是如果使用的话，我会期待下面的分工：

• itemReader 从输入源读取项目，并返回下一个要处理的项目。此类必须是线程安全的。
• itemProcessor 只返回输入项。如果有关于操作的业务规则，它们属于这里。此类不必是线程安全的，因为它是在自己的线程中调用的。此类不应写入数据库。
• itemWriter 在块大小操作之后执行插入/更新/删除和提交。

另外，我怀疑 ADD 操作不会有 userId。这通常是在插入记录时由数据库分配的。