Spring Batch 体系结构
Spring Batch 架构
Spring Batch 在设计时考虑了可扩展性和多样化的最终用户群体。这 下图显示了支持可扩展性和易用性的分层架构 供最终用户开发人员使用。
这种分层架构突出了三个主要的高级组件：应用程序、
核心和基础设施。该应用程序包含所有批处理作业和编写的自定义代码
由使用 Spring Batch 的开发人员提供。Batch Core 包含核心运行时类
启动和控制批处理作业所必需的。它包括 、 和 的实现。Application 和 Core 都构建在通用的
基础设施。此基础结构包含常见的读取器和写入器以及服务
（例如 ），它们由应用程序开发人员（readers 和
编写器（如 and）和核心框架本身（重试、
这是它自己的库）。JobLauncherJobStepRetryTemplateItemReaderItemWriter
一般 Batch 原则和准则
应考虑以下关键原则、指南和一般注意事项 构建批处理解决方案时。
-
请记住，批处理架构通常会影响在线架构和副 反之亦然。使用通用架构进行设计时同时考虑架构和环境 阻止。
-
尽可能简化并避免在单个 批处理应用程序。
-
使数据的处理和存储在物理上紧密相连（换句话说，保持 您的数据）。
-
最大限度地减少系统资源使用，尤其是 I/O。在 内部存储器。
-
查看应用程序 I/O（分析 SQL 语句）以确保不必要的物理 I/O 被避免。特别需要寻找以下四个常见缺陷：
-
当数据可以读取一次并缓存或保留时，为每个事务读取数据 在工作仓库中。
-
重新读取数据的交易中的数据，其中数据是在同一交易中较早读取的 交易。
-
导致不必要的表或索引扫描。
-
未在 SQL 语句的子句中指定键值。
WHERE
-
-
不要在批处理运行中执行两次操作。例如，如果您需要 出于报告目的，您应该（如果可能）在数据 初始处理，因此您的 Reporting Application 不必重新处理相同的 数据。
-
在批处理应用程序开始时分配足够的内存以避免耗时 重新分配。
-
在数据完整性方面，始终假设最坏的情况。插入适当的检查和 记录验证以保持数据完整性。
-
尽可能实施内部验证的校验和。例如，平面文件 应有一个 trailer 记录，告知文件中的记录总数以及 键字段。
-
在类似生产的环境中尽早规划和执行压力测试 具有真实的数据量。
-
在大型批处理系统中，备份可能具有挑战性，尤其是在系统正在运行时 与 24/7 的在线应用程序同时进行。数据库备份通常得到很好的照顾 of 的，但文件备份也应该被视为同样重要。 如果系统依赖于平面文件，则不仅应制定文件备份程序 并记录在案，但也要定期测试。
批处理策略
为了帮助设计和实现批处理系统，基本的批处理应用程序构建块和 模式应以 sample 的形式提供给设计人员和程序员 结构图和代码 shell。开始设计批处理作业时，业务逻辑 应该分解为一系列的步骤，这些步骤可以使用以下方法实现 标准构建块：
-
转换应用：对于 外部系统，必须创建一个转换应用程序才能转换交易 以处理所需的标准格式提供的记录。这种类型的批处理 应用程序可以部分或全部由翻译工具模块组成（请参阅基本 Batch 服务）。
-
验证应用：验证应用程序可确保所有输入和输出 记录正确且一致。验证通常基于文件头和 trailers、校验和和验证算法，以及记录级交叉检查。
-
提取应用：提取应用程序从数据库中读取一组记录，或者 input file，根据预定义的规则选择记录，并将记录写入 output 文件。
-
提取/更新应用程序：提取/更新应用程序从数据库中读取记录，或者 输入文件，并根据找到的数据对数据库或输出文件进行更改 在每个输入记录中。
-
处理和更新应用程序：处理和更新应用程序对 从 Extract 或 Validation 应用程序输入交易。处理通常 涉及读取数据库以获取处理所需的数据，可能还会更新 数据库并创建用于输出处理的记录。
-
输出/格式应用程序：输出/格式化应用程序读取输入文件，重组数据 根据标准格式从此记录中生成用于打印的输出文件 或传输到其他程序或系统。
此外，应该为不能 使用前面提到的构建块构建。
除了主要构建块之外，每个应用程序还可以使用一个或多个标准 实用工具步骤，例如：
-
排序：读取输入文件并生成输出文件的程序，其中记录 已根据记录中的 Sort Key 字段重新排序。排序通常是 由标准 System Utilities 执行。
-
Split：读取单个输入文件并将每条记录写入以下之一的程序 基于字段值的多个输出文件。拆分可以定制或执行 参数驱动的 Standard System Utilities。
-
合并：从多个输入文件中读取记录并生成一个输出的程序 文件，其中包含来自输入文件的组合数据。合并可以由 参数驱动的 Standard System Utilities。
Batch 应用程序还可以按其输入源进行分类：
-
数据库驱动的应用程序由从数据库中检索的行或值驱动。
-
文件驱动应用程序由从文件中检索的记录或值驱动。
-
消息驱动的应用程序由从消息队列中检索的消息驱动。
任何批处理系统的基础都是处理策略。影响 策略的选择包括：估计的批处理系统卷、并发性 在线系统或与其他批处理系统一起使用，可用的批处理窗口。（请注意，使用 更多企业希望启动并运行 24x7 全天候运行，Clear Batch 窗口是 消失）。
批处理的典型处理选项是（按实现的升序排列 复杂性）：
-
脱机模式下批处理窗口期间的正常处理。
-
并发批处理或联机处理。
-
同时并行处理许多不同的批处理运行或作业。
-
分区 （同时处理同一作业的多个实例）。
-
上述选项的组合。
商业调度程序可能支持其中的部分或全部选项。
本节的其余部分将更详细地讨论这些处理选项。 请注意，根据经验，批处理采用的提交和锁定策略 进程取决于所执行的处理类型以及在线锁定 策略也应该使用相同的原则。因此，批处理架构不能 只是在设计整体架构时事后才想到的。
锁定策略可以是仅使用普通数据库锁或实现 体系结构中的其他自定义锁定服务。锁定服务将跟踪 数据库锁定（例如，通过将必要的信息存储在专用的 database 表），并授予或拒绝请求数据库的应用程序的权限 操作。此架构也可以实现重试逻辑，以避免中止 批处理作业。
1. 在批处理窗口中进行正常处理 对于在单独的 批处理窗口，在线用户或其他批处理不需要正在更新的数据 进程，并发性不是问题，并且可以在 batch 运行。
在大多数情况下，更健壮的方法更合适。请记住，批次 随着时间的推移，系统在复杂性和数据方面都有增长的趋势 他们处理的量。如果没有锁定策略，并且系统仍然依赖于 单个提交点，修改批处理程序可能会很痛苦。因此，即使使用 最简单的批处理系统，考虑需要 Commit logic 进行重启恢复 选项以及有关稍后 本节。
2. 并发批处理或在线处理 批处理应用程序处理可以 同时由在线用户更新时，不应锁定任何数据（在 数据库或文件中），而在线用户可能需要多个 秒。此外，应在每隔几次结束时将更新提交到数据库 交易。这样做可以最大程度地减少其他进程不可用的数据部分 以及数据不可用的运行时间。
最小化物理锁定的另一种选择是具有逻辑行级锁定 使用 Optimistic Locking Pattern 或 Pessimistic Locking Pattern 实现。
-
乐观锁定假定记录争用的可能性较低。它通常意味着 在每个数据库表中插入一个 timestamp 列，该列由 Batch 和 在线处理。当应用程序获取一行进行处理时，它还会获取 时间戳。然后，当应用程序尝试更新已处理的行时，更新将使用 原始时间戳。如果时间戳匹配，则 data 和 timestamp 更新。如果时间戳不匹配，则表示另一个 应用程序在获取和更新尝试之间更新了同一行。因此 无法执行更新。
WHERE -
悲观锁定是假设存在极高可能性的任何锁定策略 记录争用，因此需要在 检索时间。一种类型的悲观逻辑锁定在 数据库表。当应用程序检索要更新的行时，它会在 Lock 列。设置该标志后，其他尝试检索 同一行在逻辑上失败。当设置标志的应用程序更新行时，它还会 清除该标志，使该行可由其他应用程序检索。请注意， 还必须在 initial fetch 和 setting 的标志 — 例如，通过使用数据库锁（例如 ）。另请注意， 这种方法与物理锁定具有相同的缺点，只是它有点 更易于管理构建超时机制，如果用户 在记录被锁定时去吃午饭。
SELECT FOR UPDATE
这些模式不一定适合批处理，但可能会使用 用于并发批处理和联机处理（例如，在数据库没有 支持行级锁定）。一般来说，乐观锁定更适合 在线应用程序，而悲观锁定更适合批处理应用程序。 无论何时使用逻辑锁定，都必须对所有应用程序使用相同的方案 访问受逻辑锁保护的数据实体。
请注意，这两种解决方案都只解决了锁定单个记录的问题。通常，我们可能会 需要锁定逻辑上相关的记录组。使用物理锁时，您必须 请非常小心地管理这些漏洞，以避免潜在的死锁。使用逻辑锁，它 通常最好构建一个理解逻辑记录的 Logic Lock Manager 组，可以确保锁是一致的，并且 非死锁。此逻辑锁管理器通常使用自己的表进行锁 管理、争用报告、超时机制和其他问题。
3. 并行处理 并行处理允许多个批处理运行或作业在 parallel 以最大程度地减少总已用批处理时间。这不是问题，因为 只要 Job 不共享相同的文件、数据库表或索引空间。如果他们这样做， 此服务应使用分区数据实现。另一种选择是构建一个 architecture 模块，用于使用控制表维护相互依赖关系。A 控件 table 中应包含每个共享资源的一行，以及它是否由 申请与否。批处理体系结构或并行作业中的应用程序将 然后从该表中检索信息，以确定它是否可以访问 资源。
如果数据访问没有问题，可以通过 使用其他线程进行并行处理。在大型机环境中，并行 传统上使用 job 类，以确保所有 CPU 都有足够的 CPU 时间 过程。无论如何，该解决方案必须足够健壮，以确保 所有正在运行的进程。
并行处理中的其他关键问题包括负载平衡和 常规系统资源，例如文件、数据库缓冲池等。另外，请注意， 控制表本身很容易成为关键资源。
4. 分区 使用分区允许多个版本的大型批处理应用程序 同时运行。这样做的目的是减少所需的运行时间 处理较长的批处理作业。可以成功分区的进程是 可以拆分输入文件或对主数据库表进行分区，以允许 应用程序针对不同的数据集运行。
此外，分区的进程必须设计为仅处理其 分配的数据集。分区架构必须与数据库紧密相连 设计和数据库分区策略。请注意，数据库分区不会 必然意味着数据库的物理分区（尽管在大多数情况下，这是 建议）。下图说明了分区方法：
架构应该足够灵活，以允许动态配置数字 的分区。您应该考虑自动和用户控制的配置。 自动配置可能基于输入文件大小和 输入记录数。
4.1 分区方法选择分区方法必须在 根据具体情况。以下列表描述了一些可能的分区 方法：
1. 记录集的固定甚至分解
这涉及将输入记录集分成偶数个部分（例如 10，其中每个部分正好占整个记录集的 1/10）。然后，每个部分都是 由 Batch/Extract 应用程序的一个实例处理。
要使用此方法，需要预处理以拆分记录设置。这 此拆分的结果是您可以使用的下限和上限放置编号 作为 Batch/Extract 应用程序的输入，以将其处理限制为仅其 部分。
预处理可能是一个很大的开销，因为它必须计算和确定边界 记录集的每个部分。
2. 按 Key 列拆分
这涉及到按键列（例如位置代码）拆分输入记录集。 以及将每个键中的数据分配给批处理实例。为此，列 值可以是：
-
由分区表分配给 batch 实例（稍后将对此进行描述 部分）。
-
按值的一部分（如 0000-0999、1000 - 1999、 等等）。
在选项 1 下，添加新值意味着手动将批次或数据提取重新配置为 确保将新值添加到特定实例。
在选项 2 下，这可确保批处理的实例涵盖所有值 工作。但是，一个实例处理的值的数量取决于 列值的分布（0000-0999 中可能有大量位置 范围，很少在 1000-1999 范围内）。在此选项下，数据范围应为 设计时考虑了分区。
在这两个选项下，记录到批处理实例的最佳均匀分布不能为 实现。使用的批处理实例数没有动态配置。
3. 按视图细分
这种方法基本上是按键列分解，但在数据库级别。它涉及 将 Record Set 拆分为 views。这些视图由批处理的每个实例使用 应用程序。通过对数据进行分组来完成分解。
使用此选项时，必须将批处理应用程序的每个实例配置为命中 特定视图（而不是主表）。此外，随着新数据的添加 值，则必须将这组新数据包含在视图中。没有动态 配置功能，因为实例数的更改会导致 视图。
4. 添加处理指示符
这涉及向输入表中添加一个新列，该列充当 指示器。作为预处理步骤，所有指标都标记为未处理。 在批处理应用程序的记录获取阶段，根据条件读取记录 单个记录被标记为未处理，并且一旦读取（带锁）， 它被标记为正在处理。当该记录完成时，指示器为 更新为 Complete 或 Error。您可以启动批处理应用程序的多个实例 没有更改，因为 Additional 列可确保记录仅处理一次。
使用此选项，表上的 I/O 将动态增加。在更新的情况下 batch 应用程序，则此影响会减少，因为无论如何都必须进行写入。
5. 将 Table 提取到平面文件
此方法涉及将表提取到平面文件中。然后可以将此文件拆分为 多个区段，并用作 Batch 实例的输入。
使用此选项，将表提取到文件中的额外开销以及 拆分它可能会抵消多分区的效果。动态配置可以 通过更改文件拆分脚本来实现。
6. 哈希列的使用
此方案涉及向数据库表添加哈希列（键或索引） 用于检索驱动程序记录。此哈希列有一个指示符，用于确定哪个 实例处理此特定行。例如，如果存在 是三个要启动的批处理实例，则 'A' 的指示符标记一行 由实例 1 处理，指示符 'B' 标记一行由实例 2 处理， 指示符 'C' 标记要由实例 3 处理的行。
然后，用于检索记录的过程将具有一个附加子句
以选择由特定指示器标记的所有行。此表中的插入内容将
涉及添加 marker 字段，该字段默认为
实例（例如 'A'）。WHERE
将使用简单的批处理应用程序来更新指标，例如 在不同实例之间重新分配负载。当一个足够大的数字 of new rows 已添加，则可以运行此批处理（任何时间，批处理窗口中除外） 将新行重新分配给其他实例。
批处理应用程序的其他实例只需要运行批处理 应用程序（如前几段所述）将指标重新分发到 使用新数量的实例。
4.2 数据库和应用程序设计原则
支持针对 分区数据库表并使用键列方法应包括一个中央 partition 存储库，用于存储分区参数。这提供了灵活性和 确保可维护性。存储库通常由一个表组成，称为 分区表。
存储在分区表中的信息是静态的，通常应进行维护 由 DBA 提供。该表应包含 多分区应用程序。该表应包含项目 ID 代码、 分区编号（分区的逻辑 ID），此数据库键列的低值 partition 的 ID 和此分区的数据库键列的 High Value。
在程序启动时，程序和分区号应该传递给
应用程序（具体来说，来自 Control Processing Tasklet）。如果
使用键列方法，这些变量用于读取分区表
确定应用程序要处理的数据范围。此外，
在整个处理过程中必须使用分区号，以便：id
-
添加到输出文件或数据库更新，以便合并过程正常工作 适当地。
-
将正常处理报告给 batch 日志，将任何错误报告给架构错误 处理器。
4.3 最小化死锁
当应用程序并行运行或分区时，会争用数据库资源 并且可能会发生死锁。数据库设计团队消除 作为数据库设计的一部分。
此外，开发人员必须确保数据库索引表的设计具有 考虑死锁预防和性能。
死锁或热点通常发生在管理表或架构表中，例如 log 表、控制表和锁定表。应考虑这些影响 帐户也是如此。真实的压力测试对于识别可能的 架构中的瓶颈。
为了最大限度地减少冲突对数据的影响，架构应该提供服务 （例如等待和重试间隔）附加到数据库或遇到 僵局。这意味着一个内置的机制来响应某些数据库返回代码，并且 而不是立即发出错误，而是等待预定的时间，然后 重试数据库操作。
4.4 参数传递和验证
分区体系结构对于应用程序开发人员来说应该是相对透明的。 该架构应执行与在 分区模式，包括：
-
在应用程序启动之前检索分区参数。
-
在应用程序启动之前验证分区参数。
-
在启动时将参数传递给应用程序。
验证应包括检查以确保：
-
应用程序具有足够的分区来覆盖整个数据范围。
-
分区之间没有间隙。
如果数据库已分区，则可能需要一些额外的验证来确保 单个分区不跨数据库分区。
此外，体系结构应考虑分区的合并。 关键问题包括：
-
在进入下一个作业步骤之前，必须完成所有分区吗？
-
如果其中一个分区中止，会发生什么情况？