如何通过JPA实现并发批量更新同步（多副本部署场景）

关于READ_UNCOMMITTED隔离级别的疑问 #

READ_UNCOMMITTED是最低隔离级别，允许读取未提交的数据，完全无法解决并发重复处理的问题——它既不会阻止其他事务读取你正在处理的数据，也不会锁定数据避免被修改。而且不需要先执行更新，但这个隔离级别本身就不适合你的场景，应该直接放弃。

为什么@Lock(PESSIMISTIC_WRITE)未达预期 #

Spring的@Lock(PESSIMISTIC_WRITE)默认生成SELECT ... FOR UPDATE语句，但在MSSQL中，这种锁是阻塞式的：多个事务同时查询符合条件的车辆时，后续事务会被阻塞直到前序事务提交，不会跳过已锁定的行。如果你的校验逻辑耗时久，会严重拖垮性能；另外如果查询条件未命中主键/索引导致表锁，或者事务范围没有覆盖“查询-校验-更新”全流程，锁提前释放，都会出现重复处理的情况。

正确的数据库层面同步方案 #

方案1：先更新再查询（推荐，原子性最强） #

把“查询符合条件车辆”和“标记为处理中”合并为原子更新操作，彻底消除中间时间窗口：

1. 用UPDATE ... OUTPUT语句，一次性将符合条件的N辆DIRTY状态车辆更新为中间状态（比如WASHING），同时返回这些车辆的信息。
2. 对返回的车辆执行复杂校验，校验通过则更新为WASHED；不通过则改回DIRTY。

MSSQL示例SQL：

UPDATE TOP(@N) CAR
SET status = 'WASHING'
OUTPUT inserted.id, inserted.brand, inserted.status
WHERE brand = @brand AND status = 'DIRTY';

这种方式利用MSSQL的OUTPUT子句，原子性完成“锁定-更新-返回”，完全避免并发重复抓取。后续操作仅针对已锁定的车辆，不会和其他事务冲突。

方案2：悲观锁+跳过已锁定行 #

如果必须先查询再校验，可在查询时使用WITH (UPDLOCK, READPAST)锁提示：

1. 查询符合条件的车辆时添加锁提示：

SELECT TOP(@N) id, brand, status
FROM CAR WITH (UPDLOCK, READPAST)
WHERE brand = @brand AND status = 'DIRTY';

2. 保持事务直到校验完成并将状态更新为WASHED。

UPDLOCK会对行加更新锁，阻止其他事务修改或加更新锁；READPAST让当前事务跳过已被锁定的行，直接获取下一批可用车辆，避免阻塞。

方案3：乐观锁（适合低并发场景） #

给CAR表新增version字段（整数，每次更新自增）：

1. 查询符合条件的车辆时，同时获取version值。
2. 校验完成后更新状态时带上version条件：

UPDATE CAR
SET status = 'WASHED', version = version + 1
WHERE id = @id AND status = 'DIRTY' AND version = @version;

3. 检查更新影响行数，若为0说明该行已被其他事务修改，需重新抓取车辆。

这种方式无需显式锁，通过版本号冲突检测并发修改，但高并发下会出现较多重试，仅适合并发量较低的场景。

注意事项 #

• 无论采用哪种方案，事务范围必须覆盖“抓取车辆-校验-最终更新”全流程，避免锁提前释放。
• 确保查询条件（brand、status）有合适的索引，让锁仅作用于符合条件的行，提升并发性能。

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