多个Spring Batch批处理应用能否共用同一套meta data表？

默认场景下绝对不要直接复用，强行复用大概率会导致两个批处理应用都出现运行故障。

主流批处理框架（比如Spring Batch、Azure 批处理服务内置的运行时组件）的元数据表设计，本身就是绑定单组批处理作业生命周期的，直接跨应用复用会有几个明确的问题：

• 版本冲突风险：batch-a和batch-b上线间隔数月，大概率依赖的批处理框架版本不一致。应用启动时框架会自动校验元数据表结构版本，版本不匹配时会触发内置的表结构更新SQL，直接把batch-a正在使用的表结构改坏，导致batch-a运行中的作业、历史作业调度全部异常。
• 运行逻辑冲突：就算两个应用的框架版本完全一致，元数据表里的作业实例ID、执行状态、执行上下文都是全局生成、全局读写的。两个应用同时往同一组表写数据时，会出现主键冲突、作业状态互相覆盖、调度记录错乱的问题——比如batch-a正在运行的作业状态被batch-b的启动流程误更新为失败，或者batch-b的作业触发batch-a的重复执行逻辑，直接造成业务数据漏处理、重复处理。
• 运维风险：共用元数据表意味着两个应用的数据库账号都持有这组表的完整读写权限，后续任意一方做版本升级、历史数据清理、故障修复操作，都会直接影响另一个应用，出问题时排查链路极长，很难快速定位脏数据来源。

如果确实受数据库资源限制，必须在同一个on-prem数据库里部署，不要直接复用已有表，按下面的方案做隔离：

给每个批处理应用配置独立的元数据表前缀，比如batch-a的元数据表统一用BATCH_A_前缀，batch-b的统一用BATCH_B_前缀，各自启动时初始化自己专属的那组元数据表，从物理表层面做完全隔离。

不推荐尝试给同一组表加租户字段做逻辑隔离的方案，这类方案需要修改框架底层的元数据读写逻辑，后续框架版本升级时大概率出现兼容问题，维护成本极高。

最稳妥的实践永远是：每个独立部署、独立运维的批处理应用，都使用自己专属的元数据表，不要为了省几兆的表存储空间，共用其他应用正在运行的元数据表，这点建表的成本远低于后续故障带来的业务损失。

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