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