Spring Batch 文档

附录

常见问题

常见问题

是否可以在多个线程或多个进程中执行作业？

有三种方法可以实现这一点——但我们建议在分析此类需求时谨慎（这真的有必要吗？）。

向步骤中添加一个 TaskExecutor。用于配置步骤的 `StepBuilder` 具有可以设置的“taskExecutor”属性。只要步骤本质上是可重新启动的（实际上是幂等的），此方法就有效。并行作业示例展示了它在实践中如何工作——这使用“进程指示器”模式在业务事务内部将输入记录标记为已完成。

使用 PartitionStep 将您的步骤执行显式地分配给多个 Step 实例。Spring Batch 为此（PartitionHandler）提供了主要策略的本地多线程实现，这使其成为 I/O 密集型作业的绝佳选择。请记住，对于以这种方式执行的步骤中的有状态组件，请使用 scope="step"，以便为每个步骤执行创建单独的实例，并且线程之间没有交叉通信。

使用 spring-batch-integration 模块中实现的远程分块方法。这需要一些持久的中间件（例如 JMS）来实现驱动步骤和远程工作程序之间可靠的通信。基本思想是在驱动进程上使用特殊的 ItemWriter，并在工作进程上使用监听器模式（通过 ChunkProcessor）。

如何使 ItemReader 线程安全？

您可以同步 read() 方法（例如，通过将其包装在一个执行同步的委托器中）。请记住，您将失去可重新启动性，因此最佳实践是将步骤标记为不可重新启动，并且为了安全（和高效），您还可以将读取器的 saveState=false 设置为 false。

Spring Batch 对灵活策略和默认实现的使用有什么理念？你能为这个或那个属性添加一个公共 getter 吗？

Spring Batch 为框架开发人员（而不是业务逻辑实现者）提供了许多扩展点。我们期望客户端创建自己更具体的策略，这些策略可以插入以控制诸如提交间隔 ( CompletionPolicy )、处理异常的规则 ( ExceptionHandler ) 等等。

通常，我们试图劝阻用户扩展框架类。Java 语言在将类和接口标记为内部方面没有给我们太多的灵活性。通常，您可以期望 org.springframework.batch.* 包中源代码树顶层的任何内容都是公共的，但不一定是可子类化的。不鼓励扩展我们大多数策略的具体实现，而倾向于组合或分叉方法。如果您的代码只能使用 Spring Batch 的接口，那将为您提供最大的可移植性。

Spring Batch 与 Quartz 有何不同？它们是否都可以在解决方案中占有一席之地？

Spring Batch 和 Quartz 具有不同的目标。Spring Batch 提供处理大量数据的功能，而 Quartz 提供调度任务的功能。因此，Quartz 可以补充 Spring Batch，但它们不是相互排斥的技术。一个常见的组合是使用 Quartz 作为 Spring Batch 作业的触发器，使用 Cron 表达式和 Spring Core 便利的 SchedulerFactoryBean。

如何使用 Spring Batch 调度作业？

使用调度工具。市面上有许多这样的工具。例如：Quartz、Control-M、Autosys。Quartz 没有 Control-M 或 Autosys 的所有功能——它应该轻量级。如果你想要更轻量级的，你只需使用操作系统（cron、at 等）。

可以使用 Spring Batch 的作业-步骤模型和 Spring Batch 中的非顺序功能来实现简单的顺序依赖关系。我们认为这很常见。事实上，它使得纠正调度器的一个常见误用变得更容易——配置了数百个作业，其中许多不是独立的，而只是依赖于另一个。

Spring Batch 如何通过并行处理或其他方式帮助项目优化性能和可伸缩性？

我们认为这是 Job 或 Step 的职责之一。Step 的特定实现处理分解业务逻辑并在并行进程或处理器之间有效共享它的问题（请参阅 PartitionStep）。这里有许多技术可以发挥作用。其本质只是一组对分布式代理的并发远程调用，这些代理可以处理一些业务处理。由于业务处理通常已经模块化——例如，输入一个项目，处理它——Spring Batch 可以通过多种方式策略化分发。我们有过一些经验的一种实现是一组处理业务处理的远程 Web 服务。我们将输入的主键的特定范围发送到许多远程调用中的每一个。相同基本策略适用于任何 Spring Remoting 协议（纯 RMI、HttpInvoker、JMS、Hessian 等），只需更改执行层配置中的几行代码。

如何使用消息传递来扩展批处理架构？

现有项目的大量实践证据表明，批处理的管道方法非常有益，可提高弹性和高吞吐量。我们经常面临任务关键型应用程序，其中审计跟踪至关重要，并且需要保证处理，但在负载下的性能受到极其严格的限制，或者高吞吐量带来竞争优势。

Matt Welsh 的工作表明，分阶段事件驱动架构 (SEDA) 比更僵化的处理架构具有巨大的优势，并且面向消息的中间件（JMS、AQ、MQ、Tibco 等）为我们提供了大量的开箱即用弹性。在下游和上游阶段之间存在反馈的系统中，尤其有益，因此可以调整消费者数量以适应需求量。那么这如何适应 Spring Batch 呢？spring-batch-integration 项目在 Spring Integration 中实现了这种模式，并且可以用于扩展任何处理许多项目的步骤的远程处理。特别是，请参阅“chunk”包，以及其中的 ItemWriter 和 ChunkRequestHandler 实现。

术语表