Quarkus多容器场景下数据库记录并发访问问题如何解决？

针对你遇到的多容器并发读写数据库记录、导致重复处理的问题，结合你提到的PESSIMISTIC_WRITE锁未生效的情况，给出以下几种可行方案：

1. 修正悲观锁的使用方式 #

你之前的悲观锁未生效，大概率是锁的时机不对——如果先查询记录再尝试加锁，其他容器可能已经在加锁前读取了该记录。正确的做法是在查询阶段就直接加行锁，确保只有当前事务能操作这条记录。

示例代码（JPA方式）：

import jakarta.persistence.LockModeType;
import jakarta.persistence.EntityManager;
import jakarta.transaction.Transactional;
import java.util.Optional;

@Transactional
public Optional<YourRecordEntity> fetchAndLockPendingRecord() {
    return entityManager.createQuery(
            "SELECT r FROM YourRecordEntity r WHERE r.status = 'YES'", YourRecordEntity.class)
            .setLockMode(LockModeType.PESSIMISTIC_WRITE)
            .setMaxResults(1)
            .getResultStream()
            .findFirst();
}

调用这个方法拿到记录后，直接更新状态为NO并提交事务，其他容器在查询时会被阻塞，直到当前事务释放锁。同时要确保：

• 事务范围覆盖查询+更新的全流程
• 数据库支持行级锁（避免因无索引导致锁表）

2. 使用乐观锁+版本控制 #

如果悲观锁的阻塞不符合你的性能需求，可以用乐观锁机制：给实体类添加版本字段，更新时通过版本号判断是否有并发修改，只有版本匹配的更新才会生效。

示例代码：

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Version;

@Entity
public class YourRecordEntity {
    @Id
    @GeneratedValue
    private Long id;
    private String status;
    @Version // 乐观锁版本字段
    private Long version;

    // getter、setter省略
}

处理逻辑：

@Transactional
public boolean processRecord(Long recordId) {
    YourRecordEntity record = entityManager.find(YourRecordEntity.class, recordId);
    if ("YES".equals(record.getStatus())) {
        record.setStatus("NO");
        entityManager.merge(record);
        return true; // 处理成功
    }
    return false; // 已被处理
}

当并发更新时，第二个容器的merge会抛出OptimisticLockingFailureException，此时可以捕获异常后重新查询可用记录，避免重复处理。

3. 数据库原子更新（最推荐） #

直接利用数据库的原子性操作，在更新语句中加入状态筛选条件，确保只有未处理的记录会被更新，从根源避免并发冲突。

方式一：单条记录原子更新 #

@Transactional
public int markRecordAsProcessed(Long recordId) {
    return entityManager.createQuery(
            "UPDATE YourRecordEntity r SET r.status = 'NO' WHERE r.id = :id AND r.status = 'YES'")
            .setParameter("id", recordId)
            .executeUpdate();
}

返回值为1表示更新成功（记录未被处理），返回0表示记录已被其他容器处理，无需再操作。

方式二：批量获取可处理记录（高效无阻塞） #

如果数据库支持SKIP LOCKED语法（如PostgreSQL、MySQL 8.0+），可以直接跳过已被锁定的记录，获取下一条可处理的记录，避免容器等待：

@Transactional
public Optional<YourRecordEntity> getNextAvailableRecord() {
    return entityManager.createQuery(
            "SELECT r FROM YourRecordEntity r WHERE r.status = 'YES' FOR UPDATE SKIP LOCKED", YourRecordEntity.class)
            .setMaxResults(1)
            .getResultStream()
            .findFirst();
}

这种方式适合多容器大规模部署的场景，并发效率最高，不会出现容器阻塞等待的情况。

为什么之前的PESSIMISTIC_WRITE锁未生效？ #

常见原因包括：

• 查询和加锁分离：先执行无锁查询，再尝试加锁，此时其他容器已读取记录
• 事务范围过小：锁仅在当前事务内有效，若查询和更新分属不同事务，锁会提前释放
• 数据库未使用行级锁：查询语句未命中索引，导致锁表而非锁行，无法精准控制单条记录

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