Spring Batch 批量处理策略

为了帮助设计和实现批量处理系统，基本的批量应用是通过块和模式来构建的，同时也应该能够为程序开发人员和设计人员提供结构的样例和基础的批量处理程序。

当你开始设计一个批量作业任务的时候，商业逻辑应该被拆分一系列的步骤，而这些步骤又是可以通过下面的标准构件块来实现的：

转换应用程序（Conversion Applications）：针对每一个从外部系统导出或者提供的各种类型的文件，我们都需要创建一个转换应用程序来讲这些类型的文件和数据转换为处理所需要的标准格式。这个类型的批量应用程序可以是正规转换工具模块中的一部分，也可以是整个的转换工具模块（请查看：基本的批量服务（Basic Batch Services））。
校验应用程序（Validation Applications）：校验应用程序能够保证所有的输入和输出记录都是正确和一致的。校验通常是基于头和尾进行校验的，校验码和校验算法通常是针对记录的交叉验证。
提取应用（Extract Applications）：这个应用程序通常被用来从数据库或者文本文件中读取一系列的记录，并对记录的选择通常是基于预先确定的规则，然后将这些记录输出到输出文件中。
提取/更新应用（Extract/Update Applications）：这个应用程序通常被用来从数据库或者文本文件中读取记录，并将每一条读取的输入记录更新到数据库或者输出数据库中。
处理和更新应用（Processing and Updating Applications）：这种程序对从提取或验证程序传过来的输入事务记录进行处理。这处理通常包括有读取数据库并且获得需要处理的数据，为输出处理更新数据库或创建记录。
输出和格式化应用（Output/Format Applications）：一个应用通过读取一个输入文件，对输入文件的结构重新格式化为需要的标准格式，然后创建一个打印的输出文件，或将数据传输到其他的程序或者系统中。

更多的，一个基本的应用外壳应该也能够被针对商业逻辑来提供，这个外壳通常不能通过上面介绍的这些标准模块来完成。

另外的一个主要的构建块，每一个引用通常可以使用下面的一个或者多个标准工具步骤，例如：

分类（Sort）- 一个程序可以读取输入文件后生成一个输出文件，在这个输出文件中可以对记录进行重新排序，重新排序的是根据给定记录的关键字段进行重新排序的。分类通常使用标准的系统工具来执行。
拆分（Split）- 一个程序可以读取输入文件后，根据需要的字段值，将输入的文件拆分为多个文件进行输出。拆分通常使用标准的系统工具来执行。
合并（Merge）- 一个程序可以读取多个输入文件，然后将多个输入文件进行合并处理后生成为一个单一的输出文件。合并可以自定义或者由参数驱动的（parameter-driven）系统实用程序来执行.

批量处理应用程序可以通过下面的输入数据类型来进行分类：

数据库驱动应用程序（Database-driven applications）可以通过从数据库中获得的行或值来进行驱动。
文件驱动应用程序（File-driven applications）可以通过从文件中获得的数据来进行驱动。
消息驱动应用程序（Message-driven applications）可以通过从消息队列中获得的数据来进行驱动。

所有批量处理系统的处理基础都是策略（strategy）。对处理策略进行选择产生影响的因素包括有：预估批量处理需要处理的数据量，在线并发量，和另外一个批量处理系统的在线并发量，可用的批量处理时间窗口（很多企业都希望系统是能够不间断运行的，基本上来说批量处理可能没有处理时间窗口）。

针对批量处理的标准处理选项包括有：

在一个批处理窗口中执行常规离线批处理
并发批量 / 在线处理
并发处理很多不同的批量处理或者有很多批量作业在同一时间运行
分区（Partitioning），就是在同一时间有很多示例在运行相同的批量作业
混合上面的一些需求

上面列表中的顺序代表了批处理实现复杂性的排序，在同一个批处理窗口的处理最简单,而分区实现最复杂。

上面的一些选项或者所有选项能够被商业的任务调度所支持。

在下面的部分，我们将会针对上面的处理选项来对细节进行更多的说明。需要特别注意的是，批量处理程序使用提交和锁定策略将会根据批量处理的不同而有所不同。作为最佳实践，在线锁策略应该使用相同的原则。因此，在设计批处理整体架构时不能简单地拍脑袋决定，需要进行详细的分析和论证。

锁定策略可以仅仅使用常见的数据库锁或者你也可以在系统架构中使用其他的自定义锁定服务。这个锁服务将会跟踪数据库的锁（例如在一个专用的数据库表（db-table）中存储必要的信息），然后在应用程序请求数据库操作时授予权限或拒绝。重试逻辑应该也需要在系统架构中实现，以避免批量作业中的因资源锁定而导致批量任务被终止。

批量处理作业窗口中的常规处理

针对运行在一个单独批处理窗口中的简单批量处理，更新的数据对在线用户或其他批处理来说并没有实时性要求，也没有并发问题，在批处理运行完成后执行单次提交即可。

大多数情况下，一种更健壮的方法会更合适.要记住的是，批处理系统会随着时间的流逝而增长，包括复杂度和需要处理的数据量。如果没有合适的锁定策略，系统仍然依赖于一个单一的提交点，则修改批处理程序会是一件痛苦的事情。因此，即使是最简单的批处理系统，也应该为重启-恢复（restart-recovery）选项考虑提交逻辑。针对下面的情况，批量处理就更加复杂了。

并发批量 / 在线处理

批处理程序处理的数据如果会同时被在线用户实时更新，就不应该锁定在线用户需要的所有任何数据（不管是数据库还是文件），即使只需要锁定几秒钟的时间。

还应该每处理一批事务就提交一次数据库。这减少了其他程序不可用的数据数据量，也压缩了数据不可用的时间。

另一个可以使用的方案就是使用逻辑行基本的锁定实现来替代物理锁定。通过使用乐观锁（Optimistic Locking ）或悲观锁（Pessimistic Locking）模式。

乐观锁假设记录争用的可能性很低。这通常意味着并发批处理和在线处理所使用的每个数据表中都有一个时间戳列。当程序读取一行进行处理时，同时也获得对应的时间戳。当程序处理完该行以后尝试更新时，在 update 操作的 WHERE 子句中使用原来的时间戳作为条件.如果时间戳相匹配，则数据和时间戳都更新成功。如果时间戳不匹配，这表明在本程序上次获取和此次更新这段时间内已经有另一个程序修改了同一条记录,因此更新不会被执行。
悲观锁定策略假设记录争用的可能性很高，因此在检索时需要获得一个物理锁或逻辑锁。有一种悲观逻辑锁在数据表中使用一个专用的 lock-column 列。当程序想要为更新目的而获取一行时，它在 lock column 上设置一个标志。如果为某一行设置了标志位，其他程序在试图获取同一行时将会逻辑上获取失败。当设置标志的程序更新该行时，它也同时清除标志位，允许其他程序获取该行。请注意，在初步获取和初次设置标志位这段时间内必须维护数据的完整性，比如使用数据库锁（例如，SELECT FOR UPDATE）。还请注意，这种方法和物理锁都有相同的缺点，除了它在构建一个超时机制时比较容易管理。比如记录而用户去吃午餐了，则超时时间到了以后锁会被自动释放。

这些模式并不一定适用于批处理，但他们可以被用在并发批处理和在线处理的情况下（例如,数据库不支持行级锁）。作为一般规则，乐观锁更适合于在线应用，而悲观锁更适合于批处理应用。只要使用了逻辑锁，那么所有访问逻辑锁保护的数据的程序都必须采用同样的方案。

请注意：这两种解决方案都只锁定（address locking）单条记录。但很多情况下我们需要锁定一组相关的记录。如果使用物理锁，你必须非常小心地管理这些以避免潜在的死锁。如果使用逻辑锁，通常最好的解决办法是创建一个逻辑锁管理器，使管理器能理解你想要保护的逻辑记录分组（groups），并确保连贯和没有死锁（non-deadlocking）。这种逻辑锁管理器通常使用其私有的表来进行锁管理、争用报告、超时机制等等。

并行处理

并行处理允许多个批量处理运行（run）/任务（job）同时并行地运行。以使批量处理总运行时间降到最低。如果多个任务不使用相同的文件、数据表、索引空间时，批量处理这些不算什么问题。如果确实存在共享和竞争，那么这个服务就应该使用分区数据来实现。另一种选择是使用控制表来构建一个架构模块以维护他们之间的相互依赖关系。控制表应该为每个共享资源分配一行记录，不管这些资源是否被某个程序所使用。执行并行作业的批处理架构或程序随后将查询这个控制表，以确定是否可以访问所需的资源。

如果解决了数据访问的问题，并行处理就可以通过使用额外的线程来并行实现。在传统的大型主机环境中，并行作业类上通常被用来确保所有进程都有充足的 CPU 时间。无论如何，解决方案必须足够强劲，以确保所有正在运行的进程都有足够的运行处理时间。

并行处理的其他关键问题还包括负载平衡以及一般系统资源的可用性（如文件、数据库缓冲池等）。请注意，控制表本身也可能很容易变成一个至关重要的资源（有可能发生严重竞争）。

分区

分区技术允许多版本的大型批处理程序并发地（concurrently）运行。这样做的目的是减少超长批处理作业过程所需的时间。

可以成功分区的过程主要是那些可以拆分的输入文件和/或主要的数据库表被分区以允许程序使用不同的数据来运行。

此外,被分区的过程必须设计为只处理分配给他的数据集。分区架构与数据库设计和数据库分区策略是密切相关的。请注意，数据库分区并不一定指数据库需要在物理上实现分区，尽管在大多数情况下这是明智的。

下面的图片展示了分区的方法：

上图：分区处理

系统架构应该足够灵活，以允许动态配置分区的数量。自动控制和用户配置都应该纳入考虑范围。自动配置可以根据参数来决定，例如输入文件大小和/或输入记录的数量。

分区方案

面列出了一些可能的分区方案，至于具体选择哪种分区方案，要根据具体情况来确定：

固定和均衡拆分记录集

这涉及到将输入的记录集合分解成均衡的部分（例如，拆分为 10 份，这样每部分是整个数据集的十分之一）。每个拆分的部分稍后由一个批处理/提取程序实例来处理。

为了使用这种方案，需要在预处理时候就将记录集进行拆分。拆分的结果有一个最大值和最小值的位置，这两个值可以用作限制每个批处理/提取程序处理部分的输入。

预处理可能有一个很大的开销，因为它必须计算并确定的每部分数据集的边界。

通过关键字段（Key Column）拆分

这涉及到将输入记录按照某个关键字段来拆分，比如一个地区代码（location code），并将每个键分配给一个批处理实例。为了达到这个目标，也可以使用列值。

通过分区表来指派给一个批量处理实例

请查看下面的详细说明。

在使用这种方法时, 新值的添加将意味着需要手动重新配置批处理/提取程序，以确保新值被添加到某个特定的实例。

通过数据的部分值指派给一个批量处理实例

例如，值 0000-0999, 1000 – 1999, 等。

使用这种方法的时候，将确保所有的值都会被某个批处理作业实例处理到。然而，一个实例处理的值的数量依赖于列值的分布（即可能存在大量的值分布在0000-0999范围内，而在1000-1999范围内的值却很少）。如果使用这种方法，设计时应该考虑到数据范围的切分。

使用通过分区表来指派和 通过数据的部分值，在这两种方法中，并不能将指定给批处理实例的记录实现最佳均匀分布。批处理实例的数量并不能动态配置。

通过视图（Views）

这种方法基本上是根据键列来分解，但不同的是在数据库级进行分解。它涉及到将记录集分解成视图。这些视图将被批处理程序的各个实例在处理时使用。分解将通过数据分组来完成。

使用这个方法时，批处理的每个实例都必须为其配置一个特定的视图（而非主表）。当然,对于新添加的数据，这个新的数据分组必须被包含在某个视图中。也没有自动配置功能，实例数量的变化将导致视图需要进行相应的改变。

附加的处理识别器

这涉及到输入表一个附加的新列，它充当一个指示器。在预处理阶段，所有指示器都被标志为未处理。在批处理程序获取记录阶段，只会读取被标记为未处理的记录，一旦他们被读取（并加锁），它们就被标记为正在处理状态。当记录处理完成，指示器将被更新为完成或错误。批处理程序的多个实例不需要改变就可以开始，因为附加列确保每条纪录只被处理一次。

使用该选项时，表上的I/O会动态地增长。在批量更新的程序中，这种影响被降低了，因为写操作是必定要进行的。

提取表到无格式文件

这包括将表中的数据提取到一个文件中。然后可以将这个文件拆分成多个部分，作为批处理实例的输入。

使用这个选项时，将数据提取到文件中，并将文件拆分的额外开销，有可能抵消多分区处理（multi-partitioning）的效果。可以通过改变文件分割脚本来实现动态配置。

With this option, the additional overhead of extracting the table into a file, and splitting it, may cancel out the effect of multi-partitioning. Dynamic configuration can be achieved via changing the file splitting script.

使用哈希列（Hashing Column）

这个计划需要在数据库表中增加一个哈希列（key/index）来检索驱动（driver）记录。这个哈希列将有一个指示器来确定将由批处理程序的哪个实例处理某个特定的行。例如，如果启动了三个批处理实例，那么 “A” 指示器将标记某行由实例 1 来处理，“B”将标记着将由实例 2 来处理，以此类推。

稍后用于检索记录的过程（procedure）程序，将有一个额外的 WHERE 子句来选择以一个特定指标标记的所有行。这个表的插入（insert）需要附加的标记字段，默认值将是其中的某一个实例（例如“A”）。

一个简单的批处理程序将被用来更新不同实例之间的重新分配负载的指标。当添加足够多的新行时，这个批处理会被运行（在任何时间，除了在批处理窗口中）。

批处理应用程序的其他实例只需要像上面这样的批处理程序运行着以重新分配指标，以决定新实例的数量。

数据库和应用设计原则

如果一个支持多分区（multi-partitioned）的应用程序架构，基于数据库采用关键列（key column）分区方法拆成的多个表，则应该包含一个中心分区仓库来存储分区参数。这种方式提供了灵活性，并保证了可维护性。这个中心仓库通常只由单个表组成，叫做分区表。

存储在分区表中的信息应该是是静态的，并且只能由 DBA 维护。每个多分区程序对应的单个分区有一行记录，组成这个表。这个表应该包含这些列：程序 ID 编号，分区编号（分区的逻辑ID），一个分区对应的关键列（key column）的最小值，分区对应的关键列的最大值。

在程序启动时，应用程序架构（Control Processing Tasklet，控制处理微线程）应该将程序 id 和分区号传递给该程序。这些变量被用于读取分区表，来确定应用程序应该处理的数据范围（如果使用关键列的话）。另外分区号必须在整个处理过程中用来：

为了使合并程序正常工作，需要将分区号添加到输出文件/数据库更新
向框架的错误处理程序报告正常处理批处理日志和执行期间发生的所有错误

死锁最小化

当程序并行或分区运行时,会导致数据库资源的争用,还可能会发生死锁（Deadlocks）。其中的关键是数据库设计团队在进行数据库设计时必须考虑尽可能消除潜在的竞争情况。

还要确保设计数据库表的索引时考虑到性能以及死锁预防。

死锁或热点往往发生在管理或架构表上,如日志表、控制表、锁表（lock tables）。这些影响也应该纳入考虑。为了确定架构可能的瓶颈，一个真实的压力测试是至关重要的。

要最小化数据冲突的影响，架构应该提供一些服务，如附加到数据库或遇到死锁时的等待-重试（wait-and-retry）间隔时间。这意味着要有一个内置的机制来处理数据库返回码，而不是立即引发错误处理，需要等待一个预定的时间并重试执行数据库操作。

参数处理和校验

对程序开发人员来说，分区架构应该相对透明。框架以分区模式运行时应该执行的相关任务包括：

在程序启动之前获取分区参数
在程序启动之前验证分区参数
在启动时将参数传递给应用程序

验证（validation）要包含必要的检查，以确保：

应用程序已经足够涵盖整个数据的分区
在各个分区之间没有遗漏断代（gaps）

如果数据库是分区的，可能需要一些额外的验证来保证单个分区不会跨越数据库的片区。

体系架构应该考虑整合分区(partitions).包括以下关键问题:

在进入下一个任务步骤之前是否所有的分区都必须完成？
如果一个分区 Job 中止了要怎么处理？