多JVM部署的Spring Batch应用：如何确保共享文件仅被单个实例消费？

这是分布式Spring Batch部署里很常见的痛点，我给你整理了几个经过生产环境验证的解决方案，你可以根据自己的架构复杂度、技术栈来选：

1. 原子文件重命名机制（最简单直接的方案） #

这个方案的核心是利用共享文件系统的原子重命名操作（比如NFS、SMB、GlusterFS等大多支持），步骤很清晰：

• 每个实例定期扫描共享路径下的待处理文件（比如后缀为.txt的文件）
• 当发现一个文件时，立即尝试将其原子重命名为带临时后缀的名称（比如file.txt → file.txt.inprogress）
• 只有重命名成功的实例，才拥有该文件的处理权限；重命名失败（说明已经被其他实例抢占）的实例直接跳过该文件
• 文件处理完成后，再将其重命名为.done后缀或者直接删除；如果处理失败，可把临时后缀改回原后缀，方便后续重试

优点：无需额外依赖组件，实现成本极低，性能也不错
注意点：必须确认你的共享存储支持原子重命名操作，避免多个实例同时修改文件的情况

2. 分布式锁方案（通用性最强） #

通过分布式锁保证同一时间只有一个实例能处理某一个文件，常用的两种实现方式：

2.1 基于数据库的分布式锁 #

• 新建一张文件处理状态表，字段至少包含file_name（主键）、locked_by（实例标识）、lock_time、status（待处理/处理中/已完成）
• 当实例要处理文件时，执行SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+支持）或者用乐观锁（版本号）来抢占锁
• 抢到锁的实例更新状态为"处理中"，处理完成后更新为"已完成"；如果实例崩溃，可通过定时任务清理超时的锁

2.2 基于Redis的分布式锁 #

• 使用Redis的SETNX命令（或Redisson提供的可重入锁），以文件名作为锁的key，实例ID作为value，并设置合理的过期时间（避免实例崩溃后锁一直占用）
• 成功获取锁的实例处理文件，处理完成后释放锁；获取失败则跳过该文件
• 推荐用Redisson的分布式锁，它自带锁续期机制，能避免长任务处理时锁过期的问题

优点：不依赖文件系统特性，适配各种共享存储场景
注意点：需要保证锁的可靠性（比如避免死锁、处理锁过期），引入数据库或Redis作为依赖

3. 利用Spring Batch自带的JobRepository排他性 #

Spring Batch的JobRepository本身就有防止同一JobInstance重复执行的机制，你可以利用这一点：

• 将文件名作为JobParameters的唯一标识（比如new JobParametersBuilder().addString("fileName", "file.txt").toJobParameters()）
• 当一个实例触发处理该文件的Job时，Spring Batch会检查是否存在相同参数的JobInstance，如果已经存在且状态不是完成/失败，就会拒绝执行
• 每个实例扫描到文件后，尝试创建对应的JobInstance，创建成功的实例处理文件，失败的则跳过

优点：完全贴合Spring Batch框架，无需额外引入组件
注意点：需要确保JobParameters的唯一性，并且要处理Job执行失败后的重试逻辑（比如手动重置JobInstance状态）

4. 引入消息队列中转（高可靠场景首选） #

把文件扫描和文件处理解耦，架构调整成这样：

• 单独一个服务（或者通过leader选举选出一个Spring Batch实例）作为文件扫描器，定期扫描共享路径，将待处理的文件信息（比如路径、名称）发送到消息队列（比如Kafka、RabbitMQ）
• 多个Spring Batch实例作为消息消费者，从队列中获取文件处理任务
• 利用MQ的消费机制保证消息只被一个实例消费（比如Kafka的分区消费、RabbitMQ的独占队列）

优点：解耦度高，可靠性强，便于扩展和监控
注意点：需要额外引入MQ组件，增加架构复杂度和运维成本

总结建议 #

• 如果架构比较简单，优先选原子文件重命名方案，快速落地
• 如果共享存储不支持原子操作，或者需要更通用的方案，选分布式锁（数据库或Redis）
• 如果想最大化利用Spring Batch的特性，选JobRepository排他性方案
• 如果是高并发、高可靠的生产场景，推荐消息队列中转方案

内容的提问来源于stack exchange，提问作者Sachin Mhetre