Spring Batch - 重新触发服务激活器答案

【问题标题】：Spring Batch - Re-triggering Service ActivatorSpring Batch - 重新触发服务激活器
【发布时间】：2020-07-19 02:23:31
【问题描述】：

我们有一个以主从模式运行的 Spring Batch 应用程序。在 master 端有一个 Reader，它查询源数据库并在将记录推送到中间表之前对记录进行一些处理。

发生这种情况时，主服务器也会并行启动从服务器。这些从属从中间表中读取受其分区约束的记录并同时开始处理它们，有5个从属在中间表中具有不同的记录分区要处理。

Master 和 Slaves 在不同的 JVM 中运行。

主设备使用 MessageChannelPartitionHandler 与从设备通信。在从机端，有一个服务激活器，它触发从中间表读取和处理记录的步骤。服务激活发生在分区消息到达指定通道时。完成后，每个从设备通过回复通道向主设备确认。

假设，如果在从源数据库中提取记录时在 Master 端出现问题，或者在将记录插入中间表时存在一些网络延迟。从属服务器看不到任何新的分区记录，因此它们的读取器会自动关闭，并且它们会过早地开始向主服务器发送回复。

但是，master端的进程还没有完全完成。从属步骤完成后，中间表中可能会有更多新记录。当这种情况发生时，所有这些溢出的记录只能在下一次 Job 运行期间进行处理。

当这种情况发生时，有没有办法从主服务器再次触发从服务器上的服务激活？换句话说，我们是否可以强制slave等到master的处理完全完成并且中间表中的所有记录都可用时，才向master发送回复消息？

【问题讨论】：

【解决方案1】：

从属步骤完成后，中间表中可以有更多的新记录

批处理是关于处理固定数据集。如果数据源在移动，它就变成了流处理。为作业分配固定数据集是可重新启动的原因。

根据您的设计，分区不是固定的。因此，您需要确保每个从站处理一组固定的记录或使用流式解决方案。

【讨论】：

对不起！，一个作业的执行将只针对一个固定的数据集。工作包括 2 个步骤。第一步从源中拉取数据，经过轻微处理后推入中间表。第二步是 Master 启动 5 个 slave 并等待它们完成。这 2 个步骤并行执行，即从属设备在第 1 个步骤仍在执行时开始处理，这意味着从属设备甚至在其分区完全填充到中间表中之前就开始处理。因此，它们也有在分区完全填充之前完成的风险。
从worker的角度来看，partition仍然是一个移动的目标。当 worker 启动时，它的 reader 已经在 table 上打开了一个游标，但之后可以添加记录。您的问题是设计问题，而不是实施问题。修复中间表中数据的步骤应该在启动 worker 之前执行，而不是与它们并行。