Spring Batch 介绍
Spring Batch 介绍
企业域中的许多应用程序都需要批量处理才能执行 任务关键型环境中的业务运营。这些业务运营包括：
-
以最高效的方式对大量信息进行自动化、复杂的处理 在没有用户交互的情况下处理。这些操作通常包括基于时间的事件 （例如月末计算、通知或通信）。
-
定期应用在非常大的 数据集（例如，保险福利确定或费率调整）。
-
集成从内部和外部系统接收的信息 通常需要以事务方式格式化、验证和处理 记录系统。批处理用于处理每个 10 亿笔交易 企业日。
Spring Batch 是一个轻量级、全面的批处理框架，旨在启用 开发对企业日常运营至关重要的强大批处理应用程序 系统。Spring Batch 建立在 Spring Framework 的特性之上，人们 已经开始期望（生产力、基于 POJO 的开发方法和一般的易用性 使用），同时使开发人员能够轻松访问和利用更高级的 Enterprise 服务。Spring Batch 不是调度框架。有很多好的 企业调度程序（如 Quartz、Tivoli、Control-M 等）在 商业和开源空间。它旨在与 scheduler 的 scheduler 中，而不是替换 scheduler。
Spring Batch 提供了处理大量数据所必需的可重用功能 记录，包括日志记录/跟踪、事务管理、作业处理统计、 作业重启、跳过和资源管理。它还提供更先进的技术 支持极高容量和高性能批处理作业的服务和功能 通过优化和分区技术。Spring Batch 可用于简单的 使用案例（例如将文件读入数据库或运行存储过程） 作为复杂的高容量使用案例（例如在数据库之间移动大量数据， 转换它，依此类推）。大容量批处理作业可以在 高度可扩展的方式来处理大量信息。
背景
虽然开源软件项目和相关社区更加关注 在基于 Web 和微服务的架构框架上，已经有 明显缺乏对可重用架构框架的关注，以适应基于 Java 的批处理 处理需求，尽管仍然需要在企业 IT 中处理此类处理 环境。由于缺乏标准的、可重用的批处理架构，导致 在客户企业 IT 中开发的许多一次性内部解决方案 功能。
SpringSource（现在的 Pivotal）和 Accenture 合作改变了这一点。埃森哲的 实施 Batch 架构的实践行业和技术经验， SpringSource 深厚的技术经验，以及 Spring 久经考验的编程模型 共同建立了自然而强大的合作伙伴关系，以创造高质量、与市场相关的 旨在填补企业 Java 中的一个重要空白的软件。两家公司都曾合作过 许多通过开发基于 Spring 的批处理来解决类似问题的客户 架构解决方案。这提供了一些有用的额外细节和现实生活 有助于确保解决方案可以应用于实际问题的约束 由客户摆姿势。
Accenture 将以前专有的批处理架构框架贡献给了 Spring Batch 项目，以及用于推动支持、增强、 和现有功能集。埃森哲的贡献基于数十年的 使用最近几代 平台：COBOL/Mainframe、C++/Unix，以及现在的 Java/anywhere。
埃森哲和 SpringSource 之间的合作旨在促进 软件处理方法、框架和工具的标准化 企业用户在创建批处理应用程序时始终利用。公司 以及希望为其提供标准、经过验证的解决方案的政府机构 企业 IT 环境可以从 Spring Batch 中受益。
使用场景
典型的批处理程序通常为：
-
从数据库、文件或队列中读取大量记录。
-
以某种方式处理数据。
-
以修改后的形式写回数据。
Spring Batch 自动执行此基本批处理迭代，从而提供处理 与一组交易类似，通常在没有任何用户的离线环境中 互动。批处理作业是大多数 IT 项目的一部分，而 Spring Batch 是唯一开放的 Source 框架，该框架提供强大的企业级解决方案。
业务场景
-
定期提交批处理
-
并发批处理：作业的并行处理
-
分阶段的企业消息驱动处理
-
大规模并行批处理
-
失败后手动或计划重启
-
依赖步骤的顺序处理（扩展为工作流驱动的批处理）
-
部分处理：跳过记录（例如，回滚时）
-
全批处理事务，适用于小批量或现有存储的情况 过程/脚本
技术目标
-
批处理开发人员使用 Spring 编程模型：专注于业务逻辑和 让框架负责基础设施。
-
基础设施和批处理执行之间的关注点明确分离 环境和 Batch 应用程序。
-
提供通用的核心执行服务作为所有项目都可以实现的接口。
-
提供核心执行接口的简单和默认实现，这些接口可以是 使用“开箱即用”。
-
利用 Spring 框架轻松配置、自定义和扩展服务 在所有图层中。
-
所有现有的核心服务都应该易于替换或扩展，并且不会对 基础设施层。
-
提供一个简单的部署模型，其中架构 JAR 与 使用 Maven 构建的应用程序。
Spring Batch 架构
Spring Batch 在设计时考虑了可扩展性和多样化的最终用户群体。这 下图显示了支持可扩展性和易用性的分层架构 供最终用户开发人员使用。
这种分层架构突出了三个主要的高级组件：应用程序、
核心和基础设施。该应用程序包含所有批处理作业和编写的自定义代码
由使用 Spring Batch 的开发人员提供。Batch Core 包含核心运行时类
启动和控制批处理作业所必需的。它包括 、 和 的实现。Application 和 Core 都构建在通用的
基础设施。此基础结构包含常见的读取器和写入器以及服务
（例如 ），它们由应用程序开发人员（readers 和
编写器（例如 和 ）和核心框架本身（重试、
这是它自己的库）。JobLauncherJobStepRetryTemplateItemReaderItemWriter
一般 Batch 原则和准则
应考虑以下关键原则、指南和一般注意事项 构建批处理解决方案时。
-
请记住，批处理架构通常会影响在线架构和副 反之亦然。使用通用架构进行设计时，同时考虑架构和环境 阻止。
-
尽可能简化并避免在单个 批处理应用程序。
-
使数据的处理和存储在物理上紧密相连（换句话说，保持 您的数据）。
-
最大限度地减少系统资源使用，尤其是 I/O。在 内部存储器。
-
查看应用程序 I/O（分析 SQL 语句）以确保不必要的物理 I/O 被避免。特别需要寻找以下四个常见缺陷：
-
当数据可以读取一次并缓存或保留时，为每个事务读取数据 在工作仓库中。
-
重新读取数据的交易中的数据，其中数据是在同一交易中较早读取的 交易。
-
导致不必要的表或索引扫描。
-
未在 SQL 语句的 WHERE 子句中指定键值。
-
-
不要在批处理运行中执行两次操作。例如，如果您需要 出于报告目的，您应该（如果可能）在数据 初始处理，因此您的 Reporting Application 不必重新处理相同的 数据。
-
在批处理应用程序开始时分配足够的内存以避免耗时 重新分配。
-
在数据完整性方面，始终假设最坏的情况。插入适当的检查和 记录验证以保持数据完整性。
-
尽可能实施内部验证的校验和。例如，平面文件 应有一个 trailer 记录，告知文件中的记录总数以及 键字段。
-
在类似生产的环境中尽早规划和执行压力测试 具有真实的数据量。
-
在大型批处理系统中，备份可能具有挑战性，尤其是在系统正在运行时 与 24/7 在线同时进行。数据库备份通常得到很好的照顾 of 的，但文件备份也应该被视为同样重要。 如果系统依赖于平面文件，则不仅应制定文件备份程序 并记录在案，但也要定期测试。
批处理策略
为了帮助设计和实现批处理系统，基本的批处理应用程序构建块和 模式应以 sample 的形式提供给设计人员和程序员 结构图和代码 shell。开始设计批处理作业时，业务逻辑 应分解为一系列步骤，这些步骤可以使用以下方法实现 标准构建块：
-
转换应用：对于由 外部系统，必须创建一个转换应用程序才能转换交易 以处理所需的标准格式提供的记录。这种类型的批处理 应用程序可以部分或全部由翻译工具模块组成（请参阅基本 Batch 服务）。
-
验证应用：验证应用程序确保所有输入/输出 记录正确且一致。验证通常基于文件头和 trailers、checksums 和验证算法，以及记录级别的交叉检查。
-
提取应用：从数据库读取一组记录的应用程序，或者 input file，根据预定义的规则选择记录，并将记录写入 output 文件。
-
提取/更新应用程序：从数据库读取记录的应用程序，或者 输入文件，并对数据库或由找到的数据驱动的输出文件进行更改 在每个输入记录中。
-
处理和更新应用程序：对 从 Extract 或 Validation 应用程序输入交易。处理通常 涉及读取数据库以获取处理所需的数据，可能还会更新 数据库并创建用于输出处理的记录。
-
输出/格式应用程序：读取输入文件、重组数据的应用程序 根据标准格式从此记录中生成用于打印的输出文件 或传输到其他程序或系统。
此外，应该为不能 使用前面提到的构建块构建。
除了主要构建块之外，每个应用程序还可以使用一个或多个标准 实用工具步骤，例如：
-
排序：读取输入文件并生成输出文件的程序，其中记录 已根据记录中的 Sort Key 字段重新排序。排序通常是 由标准 System Utilities 执行。
-
Split：读取单个输入文件并将每条记录写入以下之一的程序 基于字段值的多个输出文件。拆分可以定制或执行 参数驱动的 Standard System Utilities。
-
合并：从多个输入文件中读取记录并生成一个输出的程序 文件，其中包含来自输入文件的组合数据。合并可以由 参数驱动的 Standard System Utilities。
Batch 应用程序还可以按其输入源进行分类：
-
数据库驱动的应用程序由从数据库中检索的行或值驱动。
-
文件驱动应用程序由从文件中检索的记录或值驱动。
-
消息驱动的应用程序由从消息队列中检索的消息驱动。
任何批处理系统的基础都是处理策略。影响 策略的选择包括：估计的批处理系统卷、并发性 在线系统或与其他批处理系统一起使用，提供批处理窗口。（请注意，使用 更多企业希望启动并运行 24x7 全天候运行，Clear Batch 窗口是 消失）。
批处理的典型处理选项是（按实现的升序排列 复杂性）：
-
离线模式下的批处理窗口期间的正常处理。
-
并发批处理或在线处理。
-
同时并行处理许多不同的批处理运行或作业。
-
分区 （同时处理同一作业的多个实例）。
-
上述选项的组合。
商业调度程序可能支持其中的部分或全部选项。
以下部分将更详细地讨论这些处理选项。这很重要 请注意，根据经验，Batch 采用的 commit 和 locking 策略 进程取决于所执行的处理类型以及在线锁定 策略也应该使用相同的原则。因此，批处理架构不能 只是在设计整体架构时事后才想到的。
锁定策略可以是仅使用普通数据库锁或实现 体系结构中的其他自定义锁定服务。锁定服务将跟踪 数据库锁定（例如，通过将必要的信息存储在专用的 db-table） 并授予或拒绝请求数据库的应用程序的权限 操作。此架构也可以实现重试逻辑，以避免中止 批处理作业。
1. 在批处理窗口中进行正常处理 对于在单独的 批处理窗口，在线用户或其他批处理不需要正在更新的数据 进程，并发性不是问题，并且可以在 batch 运行。
在大多数情况下，更健壮的方法更合适。请记住，批次 随着时间的推移，系统在复杂性和数据方面都有增长的趋势 他们处理的量。如果没有锁定策略，并且系统仍然依赖于 单个提交点，修改批处理程序可能会很痛苦。因此，即使使用 最简单的批处理系统，考虑需要 Commit logic 进行重启恢复 选项以及有关稍后 本节。
2. 并发批处理或在线处理 批处理应用程序处理可以 同时由在线用户更新时，不应锁定任何数据（无论是在 数据库或文件中），在线用户可能需要多个 秒。此外，应在每隔几次结束时将更新提交到数据库 交易。这最大限度地减少了其他进程不可用的数据部分 以及数据不可用的运行时间。
最小化物理锁定的另一种选择是具有逻辑行级锁定 使用 Optimistic Locking Pattern 或 Pessimistic Locking Pattern 实现。
-
乐观锁定假定记录争用的可能性较低。它通常意味着 在每个数据库表中插入一个时间戳列，由 Batch 和 在线处理。当应用程序获取一行进行处理时，它还会获取 时间戳。然后，当应用程序尝试更新已处理的行时，更新将使用 WHERE 子句中的 original 时间戳。如果时间戳匹配，则 data 和 timestamp 更新。如果时间戳不匹配，则表示另一个 应用程序在获取和更新尝试之间更新了同一行。因此 无法执行更新。
-
悲观锁定是假设存在极高可能性的任何锁定策略 记录争用，因此需要在 检索时间。一种类型的悲观逻辑锁定在 数据库表。当应用程序检索要更新的行时，它会在 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。这些视图由批处理的每个实例使用 应用程序。通过对数据进行分组来完成分解。
使用此选项时，必须将批处理应用程序的每个实例配置为命中 特定视图（而不是 master 表）。此外，随着新数据的添加 值，则必须将这组新数据包含在视图中。没有动态 配置功能，因为实例数的更改会导致 视图。
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 数据库和应用程序设计原则
支持针对 使用 Key Column 方法的分区数据库表应包括一个中央 partition 存储库，用于存储分区参数。这提供了灵活性和 确保可维护性。存储库通常由一个表组成，称为 分区表。
存储在分区表中的信息是静态的，通常应进行维护 由 DBA 提供。该表应包含 多分区应用程序。该表应包含项目 ID 代码、 分区编号（分区的逻辑 ID），此的 db key 列的低值 partition 的 ID 和此分区的 DB key 列的 High Value。
在程序启动时，程序和分区号应该传递给
应用程序（具体来说，来自 Control Processing Tasklet）。如果
使用键列方法，这些变量用于读取
order 来确定应用程序要处理的数据范围。此外，
在整个处理过程中必须使用分区号，以便：id
-
添加到输出文件/数据库更新以使合并过程正常工作 适当地。
-
将正常处理报告给 batch 日志，将任何错误报告给架构错误 处理器。
4.3 最小化死锁
当应用程序并行运行或分区时，数据库资源中的争用 并且可能会发生死锁。数据库设计团队消除 作为数据库设计的一部分，尽可能多地存在潜在的争用情况。
此外，开发人员必须确保数据库索引表的设计具有 考虑死锁预防和性能。
死锁或热点通常发生在管理表或架构表中，例如 log 表、控制表和锁定表。应考虑这些影响 帐户也是如此。现实的压力测试对于识别可能的 架构中的瓶颈。
为了最大限度地减少冲突对数据的影响，架构应该提供服务 例如，附加到数据库或遇到 僵局。这意味着一个内置的机制来响应某些数据库返回代码，并且 而不是立即发出错误，而是等待预定的时间，然后 重试数据库操作。
4.4 参数传递和验证
分区体系结构对于应用程序开发人员来说应该是相对透明的。 该架构应执行与在 分区模式，包括：
-
在应用程序启动之前检索分区参数。
-
在应用程序启动之前验证分区参数。
-
在启动时将参数传递给应用程序。
验证应包括检查以确保：
-
应用程序具有足够的分区来覆盖整个数据范围。
-
分区之间没有间隙。
如果数据库已分区，则可能需要一些额外的验证来确保 单个分区不跨数据库分区。
此外，体系结构应考虑分区的合并。 关键问题包括：
-
在进入下一个作业步骤之前，必须完成所有分区吗？
-
如果其中一个分区中止，会发生什么情况？