Spring Batch 与批处理架构

• Job 与 Step 的层级
• Chunk 模型
• ItemReader/Processor/Writer 分工

Spring Batch 的核心概念分层：Job 是批处理任务（最高层，含多个 Step，可配流程与参数）；Step 是 Job 中的一个执行步骤（Chunk 或 Tasklet）；Chunk 是"读-处理-写"的块（一次事务处理一批数据）；ItemReader 负责读取数据（DB、文件、消息）、ItemProcessor 负责处理转换（可选，过滤/加工）、ItemWriter 负责写入数据（DB、文件）。分工：Job 组织流程，Step 定义步骤，Chunk 定义批处理单元，Reader/Processor/Writer 分别负责"读-处理-写"。开发者实现 Reader/Processor/Writer，由框架编排 Chunk 事务。

Job（任务）→ Step（步骤）→ Chunk（块/事务）→ Reader/Processor/Writer（读处理写）。分层清晰，各组件职责单一。

• Chunk 块处理
• commit-interval 提交间隔
• 事务边界与失败回滚

Chunk 模型把批处理分成多个块：每读取 commit-interval 条数据（如 100 条）作为一个 Chunk，读-处理-写后提交一次事务。commit-interval 决定每个事务处理的记录数，影响事务粒度与性能。事务边界：每个 Chunk 是一个事务，读 N 条→处理→写→提交，失败则回滚该 Chunk。失败回滚：Chunk 内某条失败，整个 Chunk 回滚（该 Chunk 内已写的不保留），从下一个 Chunk 继续。commit-interval 权衡：太大事务长、回滚代价大，太小事务频繁。合理设置平衡性能与回滚粒度。

Chunk = 读-处理-写 + 一个事务，commit-interval 控制块大小。失败回滚整个 Chunk，是批处理的事务与错误恢复模型。

• Chunk 模型（读-处理-写）
• Tasklet 模型（单任务）
• 选择边界

Chunk 模型（ItemReader/Processor/Writer）适合"大数据量、结构化处理"：按块读-处理-写，事务粒度可控，支持断点续跑，适合批量数据迁移、ETL。Tasklet 模型适合"单步原子操作"：执行一个任务（execute），如清理、初始化、单次调用，不需要分块处理，适合简单步骤或非数据流操作。选择边界：需要分块处理大量数据用 Chunk（事务、续跑、性能）；单次原子操作、非结构化数据流用 Tasklet。Chunk 适合数据批处理，Tasklet 适合步骤型任务。二者可混合（一个 Step 用 Chunk，另一个用 Tasklet）。

Chunk 适合"大数据量分块处理"（事务/续跑），Tasklet 适合"单步原子任务"。按数据流与任务性质选择。

• ItemStream 生命周期
• 持久化 reader 位置
• 断点续跑

ItemStream 接口定义 open/update/close 生命周期，用于管理流式资源的开/关与状态持久化。在批处理中，ItemReader 实现 ItemStream，open 时打开资源并恢复上次位置，update 时把当前读取位置（如行号、游标）写入 ExecutionContext（JobRepository 持久化），close 时关闭资源。重启时，Spring Batch 从 ExecutionContext 恢复 reader 位置，使任务从上次失败点继续读取，而非重头开始。这就是断点续跑：通过 ItemStream 持久化位置 + JobRepository 保存执行上下文，实现增量恢复。

ItemStream 的 open/update/close + ExecutionContext 持久化 reader 位置，重启时恢复位置实现断点续跑。这是批处理可靠性的关键。

• 条件流程（Conditional Flow）
• JobExecutionDecider 决策器
• 与固定 flow 差异

条件流程（Conditional Flow）允许根据步骤执行结果（ExitStatus）动态决定后续 Step，通过 .on(...).to(...).from(...).end() 定义分支。JobExecutionDecider 是自定义决策器，根据 job 执行上下文返回新的 FlowExecutionStatus，用于更复杂的条件分支（不限于步骤 ExitStatus）。固定 flow 则按顺序执行所有 Step（无分支）。差异：固定 flow 是线性执行，条件流程按结果分支（成功/失败/特定状态走不同路径），JobExecutionDecider 提供编程式动态分支决策。条件流程让批处理更灵活（如失败重试、跳过、按数据分支）。

条件流程按 ExitStatus 分支、JobExecutionDecider 编程式决策，固定 flow 线性执行。条件分支让批处理路径动态化。

• 分区（Partitioning）
• 远程分块（Remote Chunking）
• 提升吞吐

分区（Partitioning）把数据按分区（如按 ID 范围、按文件分片）拆分成多个子任务，由多个 worker Step 并行处理，提升吞吐（横向扩展计算）。远程分块（Remote Chunking）把 Chunk 的读-处理与写分离：master 读数据，通过消息队列把 Chunk 发给远程 worker 处理（processor/writer），worker 处理后再写，实现分布式处理并行。二者都通过并行/分布式提升吞吐：分区并行处理数据分区，远程分块分布处理与写入。配合多 worker 节点与消息中间件，扩展批处理吞吐。分区适合并行计算，远程分块适合读写分离。

分区并行处理数据分区，远程分块分布式读写，都是通过并行与分布提升批处理吞吐。按可并行性与分布需求选择。

• BATCH_JOB_* 元数据表
• JobRepository 作用
• 元数据持久化

Spring Batch 使用元数据表（BATCH_JOB_INSTANCE、BATCH_JOB_EXECUTION、BATCH_STEP_EXECUTION、BATCH_JOB_EXECUTION_PARAMS、BATCH_JOB_EXECUTION_CONTEXT 等）持久化批处理状态。JobRepository 负责管理这些元数据：保存 Job 实例、Job/Step 执行状态、执行上下文、参数、时间等，支持批处理的状态追踪、断点续跑与重启。元数据表记录每次执行的进度与状态，JobRepository 是状态持久化的核心。作用：重启恢复、状态监控、参数记录、历史追踪。数据库元数据表是批处理可靠性的基础。

BATCH_JOB_* 元数据表持久化 Job/Step 状态，JobRepository 管理元数据，支持状态追踪、断点续跑与重启。

• JobParameters 唯一性
• restart 语义
• 幂等

JobParameters 用于标识 Job 的执行参数，Spring Batch 通过 JobParameters 唯一性约束：相同 JobParameters 不能重复创建 JobInstance（幂等），防止重复执行同一参数的任务。restart 语义：Job 失败后可用相同 JobParameters 重启（restart），从上次失败点继续（借助 JobRepository 与 ItemStream 位置），而非重头。幂等保证：JobParameters 唯一性 + 断点续跑实现"重复执行安全、失败可续跑"。若需重新执行相同参数，需提供新参数或 allowRestart 配置。幂等与续跑是批处理可靠性的保障。

JobParameters 唯一性防重复执行（幂等），restart 借助元数据与位置实现断点续跑。二者保障批处理可靠性与可重入。

• skip 跳过策略
• retry 重试
• 监听器统计

Spring Batch 支持失败重试（retry）与跳过（skip）策略：retry 对可重试的异常（如临时性错误）重试指定次数（retry-limit、retryable-exception-classes）；skip 对可跳过的异常跳过该条记录（skip-limit 限制跳过上限，超过则 Job 失败）。重试与跳过结合：先重试，重试仍失败则跳过。监听器（StepExecutionListener、ItemReadListener、ItemProcessListener、ItemWriteListener）统计与处理失败（记录失败次数、写日志、回调）。配置 skip-limit、retry 与监听器实现"容错 + 统计"的批处理，兼顾吞吐与可靠性。

retry 重试临时错误、skip 跳过可跳过记录（skip-limit 上限），监听器统计与补偿。容错策略兼顾吞吐与可靠性。

• Spring Batch 批处理
• Spring Integration 消息集成
• Spring Cloud Task 任务生命周期

Spring Batch 与 Spring Integration/Spring Cloud Task 协作：Spring Batch 负责批处理（Job/Step），Spring Integration 负责消息集成（触发批处理、处理结果分发），Spring Cloud Task 负责短生命周期任务（任务启动/结束、任务状态记录、一次性的任务）。协作边界：Spring Integration 监听消息触发 Spring Batch Job，Job 结果通过 Integration 发布；Spring Cloud Task 管理 Batch Job 作为短生命周期任务（记录任务执行、指数退避）。Spring Boot 的 spring-boot-starter-batch 与 cloud-task 集成，让批处理任务在云环境可管理。边界：Batch 管数据处理，Integration 管消息，Cloud Task 管任务生命周期。

Batch 管批处理、Integration 管消息触发、Cloud Task 管任务生命周期。三者协作实现"消息触发 + 批处理 + 任务管理"。

• JdbcBatchItemWriter 批量写入
• MyBatis 批处理
• JPA batch

大批量写入性能取舍：JdbcBatchItemWriter 直接使用 JDBC 批量（addBatch/executeBatch），性能最高、控制精细，适合大批量写入；MyBatis 批处理（BatchExecutor）用 JDBC 批量执行，性能好、灵活；JPA batch 通过 hibernate.jdbc.batch_size 批量执行，但需实体管理、flush/clear 管理，性能略低于原生 JDBC，且受事务与持久化上下文影响。取舍：追求极致性能用 JdbcBatchItemWriter/MyBatis 批量；需要 ORM 映射与实体管理用 JPA batch（配 batch_size 与 clear）。大批量写入优先原生 JDBC 批量，避免 JPA 逐条 flush 的开销。

JdbcBatchItemWriter/MyBatis 用 JDBC 批量性能最高，JPA batch 需配 batch_size 与 clear，性能略低但保留 ORM 能力。按性能与映射需求取舍。

• 并行 Step（Parallel Step）
• 异步 Processor（AsyncItemProcessor）
• 虚拟线程并发

批处理的并发模型：并行 Step（Parallel Step）把多个 Step 或多个分区并行执行，提升吞吐；异步 Processor（AsyncItemProcessor + AsyncItemWriter）用线程池异步处理 Item，读-处理-写解耦异步化。虚拟线程下，异步 Processor 可用虚拟线程池执行（阻塞处理变便宜），提升并发。并发模型权衡：并行 Step 适合步骤间并行，异步 Processor 适合处理器内并行；需注意事务与线程安全（异步 Processor 的写与提交）。虚拟线程降低线程成本，但批处理仍需控制并发与事务边界。合理配置并行度与线程池提升吞吐。

并行 Step 并行步骤、异步 Processor 异步处理，虚拟线程降低线程成本。并发提升吞吐但需控制事务与线程安全。

• JobExecutionListener
• StepExecutionListener
• 埋点与监控

Spring Batch 的监听器用于在批处理生命周期各阶段执行回调：JobExecutionListener（beforeJob/afterJob，Job 前后）、StepExecutionListener（beforeStep/afterStep，Step 前后）、以及 ItemReadListener/ItemProcessListener/ItemWriteListener（Item 级）。监听器用于埋点：记录开始/结束时间、成功/失败状态、统计处理数、写日志、发告警、清理资源。埋点结合 JobRepository 元数据实现批处理监控与统计。监听器是批处理可观测性与扩展的钩子。

监听器在 Job/Step/Item 生命周期回调，用于埋点、统计、告警与资源管理，是批处理监控与扩展点。

• 游标快照（Cursor）
• 分页读取（Paging）
• 并发修改下的一致性

Reader 的游标快照（Cursor）与分页读取（Paging）在并发修改下的一致性不同：游标（JDBC 游标）基于数据库游标，读取时数据是按游标滚动获得，若数据被并发修改（插入/删除），游标位置可能偏移，导致数据重复或遗漏（取决于隔离级别）；分页读取按每页（offset/limit）查询，若并发插入/删除，分页偏移可能偏移（数据位移），导致重复/遗漏。一致性差异：游标依赖游标语义与事务隔离，分页依赖 offset 稳定性。并发修改下，两者都需考虑；游标快照在事务内相对稳定，分页在数据变化时易偏移。需结合隔离级别与只读/快照策略保证一致性。

游标快照与分页读取在并发修改下都可能偏移/重复。游标依赖游标与隔离，分页依赖 offset 稳定，需结合快照隔离保证一致。

• 调度器集成（Quartz/XXL-JOB）
• 分布式部署形态
• 协调与集群

Spring Batch 通常与调度器集成：Quartz（内置调度，cron 定时触发 Job）；XXL-JOB（分布式调度平台，任务分片、集群、监控）。集成方式：调度器在定时触发时调用 JobLauncher 启动 Batch Job。分布式部署形态：Batch Job 部署在多个节点，调度器（如 XXL-JOB）负责分片与协调，避免重复执行（利用 JobParameters 唯一性 + 分布式锁）；支持集群部署、水平扩展、任务分片。XXL-JOB 提供管理端、执行端、调度中心，分布式协调任务。Spring Batch 本身单机，分布式需调度器协调（分片、锁、幂等）。

Spring Batch 集成调度器（Quartz 定时/XXL-JOB 分布式调度），分布式部署依赖调度器分片与协调，配合 JobParameters 幂等防重复。

• JobLauncher.run 同步/异步
• 返回时机
• 多次启动同一 Job

JobLauncher.run(job, params) 启动 Job：同步方式（默认）run 阻塞直到 Job 完成，返回 JobExecution；异步方式配 TaskExecutor，run 提交异步执行，立即返回（Job 在后台执行）。返回时机差异：同步返回完成后的 JobExecution，异步立即返回（Job 未完成）。多次启动同一 Job：若 JobParameters 相同，Spring Batch 默认不允许重复创建 JobInstance（抛 JobInstanceAlreadyCompleteException 或 JobExecutionAlreadyRunningException），需用不同参数或 allowRestart。相同参数重复执行会被拒绝（幂等保护）。异步启动适合非阻塞触发，同步适合等待结果。

同步 run 阻塞返回完成结果，异步 TaskExecutor 立即返回。相同 JobParameters 重复启动被拒绝（幂等），需区别参数。

• LineMapper/FieldSet
• 行映射到领域对象
• 定长与分隔符格式

FlatFileItemReader 读取文本文件，通过 LineMapper 把每行映射为领域对象。LineMapper 内部用 FieldSet（字段集）管理解析出的字段，FieldSet 提供按索引/名称取字段（字符串、数字、日期）。定长格式用 FixedLengthTokenizer 按列宽切分，分隔符格式用 DelimitedLineTokenizer（按逗号/制表符切分），各自把行解析为 FieldSet；再通过 BeanWrapperFieldSetMapper 把 FieldSet 字段绑定到领域对象属性。这样实现"文本行 → FieldSet → 领域对象"的映射。适配：定长用 FixedLengthTokenizer，分隔符用 DelimitedLineTokenizer，映射用 BeanWrapperFieldSetMapper。

LineTokenizer 把行切为 FieldSet（定长/分隔符），FieldSetMapper 把 FieldSet 绑定到领域对象。LineMapper 串联二者完成行映射。

• Chunk 事务边界
• Process 阶段窗口
• 持锁问题

在 Chunk 模型中，事务边界覆盖"读-处理-写"：读在事务内开始，写后提交。Process 阶段（读后写前）存在窗口：读到的数据在事务内被持有，处理期间若数据被其他事务修改，可能产生不一致（读到的数据与写时不一致）。持锁问题：事务内读到的行可能持有锁（取决于数据库隔离级别与锁策略），处理时间长会长时间持锁，阻塞其他事务。缓解：缩短 Chunk（commit-interval 小）、处理阶段避免长耗时、使用合适的隔离级别与无锁读、或把"读-处理"与"写"分离。事务边界合理性决定一致性、锁竞争与性能。

Chunk 事务覆盖读处理写，Process 阶段读后写前有窗口与持锁风险。缩短 Chunk、控制处理时长、合理隔离级别缓解。

• 异步 ItemProcessor/ItemWriter
• 消息中间件集成
• 分布式处理

Spring Batch 支持异步 ItemProcessor 与 ItemWriter：AsyncItemProcessor 用线程池异步处理 Item，AsyncItemWriter 异步写入，提升处理吞吐（读-处理-写解耦异步）。与消息中间件集成：通过消息中间件（Kafka、RabbitMQ）实现远程分块（Remote Chunking）或数据读写——ItemWriter 发送消息到中间件、ItemReader 从中间件接收消息，实现分布式批处理与异步解耦。集成场景：数据经消息中间件转发、跨系统批处理、异步写入远端点。注意异步处理的事务与顺序、幂等与消息可靠性。异步 + 消息中间件提升批处理吞吐与分布式扩展。

异步 ItemProcessor/Writer 用线程池提升吞吐，消息中间件集成实现远程分块与分布式读写，需注意事务、幂等与消息可靠性。

• Spring Batch 特点
• 自研批量任务
• Flink Batch 边界

批处理框架选型边界：Spring Batch 是 JVM 生态轻量批处理框架，适合企业内常规批量（ETL、数据迁移、报表），提供事务、断点续跑、监听器，与 Spring 生态集成好，单机/集群配合调度器；自研批量任务（直接用代码循环）灵活但缺乏事务、断点、监控等通用能力，适合简单场景或特殊需求；Flink Batch 是分布式流/批处理引擎，适合大规模分布式数据处理、复杂计算、需要实时/流批一体，吞吐与扩展性强但更重、学习成本高。选型：企业常规批量用 Spring Batch；简单/特殊用自研；大规模分布式/流批一体用 Flink。按数据规模、复杂度、生态与运维成本选择。

Spring Batch 适合企业常规批量（事务/续跑），自研适合简单场景，Flink 适合大规模分布式/流批一体。按规模与复杂度选型。

• ItemProcessor 返回 null 过滤
• 过滤记录计数
• 与 skip 和 commit 统计交互

ItemProcessor 返回 null 表示该记录被过滤（不写入），是 Spring Batch 的过滤机制。被过滤的记录不传给 ItemWriter，也不算作写入。计数与统计：过滤记录不计入 commit 计数（不占 Chunk 的写），但 ItemProcessListener 可统计被过滤数。与 skip 策略交互：过滤（返回 null）不同于 skip（异常跳过）——过滤是正常处理结果（不写），skip 是异常跳过（记录异常）；过滤记录不触发 skip-limit。与 commit 统计交互：commit 统计基于写入的 Item 数，过滤记录不写入故不计入 commit，但影响 Chunk 的"读-处理-写"节奏（过滤多的 Chunk 可能写入少）。过滤是"正常丢弃"，skip 是"异常放弃"，语义不同。

返回 null 是正常过滤（不写），与 skip（异常跳过）语义不同，过滤不计入 commit 写入数，通过监听器统计。