用于经常修改源的 Spring-batch 阅读器答案

【问题标题】：Spring-batch reader for frequently modified source用于经常修改源的 Spring-batch 阅读器
【发布时间】：2015-08-28 13:01:17
【问题描述】：

我正在使用 Spring Batch，我想编写一份工作，其中我有一个 JPA 阅读器，可以从数据库中选择分页的产品集。然后我有一个处理器，它将对每个产品执行一些操作（比如说对产品A），但是对产品A执行此操作，项目处理器也将处理一些其他产品（如产品B，产品C等）。然后处理器将来到产品B，因为它是在线的并且是由读者给出的。但它已经被处理过了，因此再次处理它实际上是浪费时间/资源。应该如何实际解决这个问题 - 春季批次中是否有修改感知项目阅读器？一种解决方案是在项目处理器中检查产品是否已经被处理，并且只有在没有被处理的情况下才处理它。然而，检查产品是否已经过处理实际上是非常消耗资源的。

【问题讨论】：

标签： spring-batch

【解决方案1】：

这里有两种我会考虑的方法：

调整您所谓的“项目” - 项目是从阅读器返回的内容。根据事物的设计，您可能希望构建一个更复杂的阅读器，该阅读器可以包含依赖项，因此只循环它们一次。显然，这非常取决于您的具体用例。
使用流程指示器模式 - 流程指示器模式就是这样做的。在处理项目时，请在 db 中设置一个标志，指示它们已被处理。然后将读者的查询配置为仅读取已处理的查询（过滤掉通过流程阶段更新的查询）。

【讨论】：

谢谢。进程指示器模式看起来很有希望，但我有一个问题——如果我从数据库中读取一页项目（假设每页 1000 个），那么它们已经被读取，即使它们被第一个项目的项目处理器处理，它们仍将再次传递给项目处理器 - 再次导致重复工作。我说的对吗？
你是。通常，进程指示器的工作方式是标记要处理的元素，这样它们就不会被其他任何人抓取，然后该标记在实际处理后更新为已处理。在您的情况下，如果该项目将被标记为处理中，您不会更新它，因为它已经被读取并将在当前块中处理。
好的，我想我明白了。最后一个问题 - 就 spring-data-batch 而言，最好如何实施？我正在考虑创建一个空的Map 的ChunkListener，然后项目处理器用已处理项目的 ID 填充地图，在处理新产品之前检查他的 ID 是否不在地图中...是这样的吗？
你在ChunkListener 上是对的，但我会将标志存储在数据库中，以便在重新启动的情况下它会超出工作范围。
这不会大大降低性能吗？我将不得不在每个产品上写入数据库——这对我来说似乎太过分了。