如何为春季批处理集成配置通道和AMQ，其中所有步骤都作为从节点在另一个集群成员上运行。

Question

用于远程步骤分类的MessageChannelPartitionHandler配置的后续行动

即使第一个问题得到了回答(我想得很好)，但我觉得我很困惑，以至于我无法提出正确的问题。如果可以的话请指点我。

这里是我正在尝试构建的架构的草图。今天，我们有一个跨集群运行一个步骤的作业。我们希望将该体系结构扩展到运行n个(无界和不同的)作业，在集群中使用n个(无界和不同的)远程步骤。

我没有把工作执行和工作实例与工作混淆。我们已经在集群中运行了多个作业实例。我们需要能够以与我们已经定义的方法相同的方式运行其他可扩展的进程。

​

​

源数据全部来自步骤已知的数据库。分区程序正在为源数据库中的"where“子句定义数据范围，并将其放入stepContext中。所有实际工作都发生在stepContext中。jobContext只用于生成步骤，等待完成，并提供控制API。

将有0到n个作业同时运行，从从VM的多个作业中同时运行0到n个步骤。

每个大师的工作(或步骤？)需要自己的请求和回复通道，并扩展为自己的OutboundChannelAdapter？还是请求和回复通道是共享的？

每个大师的工作(或步骤？)需要自己的聚合器吗？这意味着每个作业(或步骤)都有自己的分区处理程序(现有的代码库可能支持该处理程序)。

从服务器上的StepLocator似乎需要跨所有步骤的单个共享replyChannel，但在我看来，messageChannelpartitionHandler每个步骤都需要一个单独的应答通道。

我认为不清楚的是(但我不清楚，因为不清楚)是如何由aggregatedReplyChannel接收单个应答通道，然后返回到正确的步骤。当然，我可能会迷路，我问错了问题。

提前谢谢你

Answer 1

每个大师的工作(或步骤？)需要自己的请求和回复通道，并扩展为自己的OutboundChannelAdapter？还是请求和回复通道是共享的？

不，没必要这么做。StepExecutionRequest是用一个相关Id来标识的，这样就可以区分它们。

每个大师的工作(或步骤？)需要自己的聚合器吗？这意味着每个作业(或步骤)都有自己的分区处理程序(现有的代码库可能支持该处理程序)。

情况不应该是这样的，因为请求是用相关ID唯一标识的(类似于前面的一点)。

从服务器上的StepLocator似乎需要跨所有步骤的单个共享replyChannel，但在我看来，messageChannelpartitionHandler每个步骤都需要一个单独的应答通道。

messageChannelpartitionHandler应该是步骤或作业范围，就像Javadoc中提到的那样(参见最后一个说明中的建议)。另外，由于应答通道是基于实例的，所以在以前的版本中存在消息交叉问题，但它是固定的这里。