Spring Batch同表读写数据遗漏问题及解决方案咨询

你遇到的问题是典型的offset分页在数据实时变更场景下的失效问题——每次处理后将数据标记为已发送（sent=true），导致总数据量减少，后续的offset偏移量对应的实际数据页会跳过原本的第二页，直接取到第三页。下面是几种可行的解决方案，按实用性和场景分类：

1. 改用键集分页（Keyset Pagination）替代Offset分页 #

这是最推荐的方案，核心是用**唯一且有序的字段（如ID、创建时间）**作为分页依据，而非基于偏移量的“第几页”。每次查询只取比上一页最后一条记录的键值更大的N条数据，完全不受中间数据状态变更的影响。

实现步骤： #

• 1.1 修改JPA Repository方法，添加基于唯一键的查询条件：

public interface YourEntityRepository extends JpaRepository<YourEntity, Long> {
    // 按ID升序，取ID大于lastId的未发送数据
    List<YourEntity> findBySentFalseAndIdGreaterThanOrderByIdAsc(Long lastId, Pageable pageable);
}

• 1.2 自定义或扩展RepositoryItemReader，维护每次查询的最后一个ID：

public class KeysetItemReader<T> extends RepositoryItemReader<T> {
    private Long lastProcessedId = 0L;
    private final YourEntityRepository repository;
    private final int pageSize;

    public KeysetItemReader(YourEntityRepository repository, int pageSize) {
        this.repository = repository;
        this.pageSize = pageSize;
    }

    @Override
    public List<T> readPage() {
        Pageable pageable = PageRequest.of(0, pageSize);
        List<YourEntity> items = repository.findBySentFalseAndIdGreaterThanOrderByIdAsc(lastProcessedId, pageable);
        if (!items.isEmpty()) {
            lastProcessedId = items.get(items.size() - 1).getId();
        }
        return (List<T>) items;
    }
}

这样每次查询的都是“未发送且ID大于上一批最后一个ID”的数据，不会因为数据被标记为已发送而导致分页偏移。

2. 读取前锁定待处理数据 #

在Reader阶段就将待处理的数据标记为处理中（processing=true），避免这些数据被后续的分页查询排除，从根源上解决offset失效的问题。同时可以用锁机制防止并发场景下的数据重复处理。

实现步骤： #

• 2.1 给实体类添加processing布尔字段，默认值为false；
• 2.2 修改Repository方法，添加悲观锁锁定查询到的数据：

public interface YourEntityRepository extends JpaRepository<YourEntity, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    List<YourEntity> findBySentFalseAndProcessingFalse(Pageable pageable);

    int updateProcessingTrueByIdIn(List<Long> ids);
}

• 2.3 在Reader读取数据后，立即将这批数据标记为处理中：

public class LockingItemReader implements ItemReader<List<YourEntity>> {
    private final YourEntityRepository repository;
    private final int pageSize;
    private int currentPage = 0;

    public LockingItemReader(YourEntityRepository repository, int pageSize) {
        this.repository = repository;
        this.pageSize = pageSize;
    }

    @Override
    public List<YourEntity> read() throws Exception {
        Pageable pageable = PageRequest.of(currentPage++, pageSize);
        List<YourEntity> items = repository.findBySentFalseAndProcessingFalse(pageable);
        if (items.isEmpty()) {
            return null;
        }
        // 标记为处理中
        repository.updateProcessingTrueByIdIn(items.stream().map(YourEntity::getId).collect(Collectors.toList()));
        return items;
    }
}

• 2.4 Processor发送通知成功后，将sent设为true，Writer保存时自动更新；处理完成后可将processing设回false或保留。

3. 预取待处理数据ID，再分批查询实体 #

先一次性查询所有未发送数据的ID，存入内存列表，后续分页基于这个固定的ID列表，而非数据库实时数据。这种方式逻辑最简单，适合数据量中等的场景。

实现步骤： #

• 3.1 添加Repository方法查询所有未发送数据的ID：

public interface YourEntityRepository extends JpaRepository<YourEntity, Long> {
    List<Long> findIdsBySentFalse();
}

• 3.2 用ListItemReader读取ID列表，再包装成读取实体的Reader：

// 预取所有未发送数据的ID
List<Long> pendingIds = yourEntityRepository.findIdsBySentFalse();

// 基于ID列表分页读取
ListItemReader<Long> idReader = new ListItemReader<>(pendingIds);
idReader.setPageSize(100); // 每次取100个ID

// 包装成读取实体的Reader
ItemReader<YourEntity> entityReader = new ItemReader<>() {
    @Override
    public YourEntity read() throws Exception {
        Long id = idReader.read();
        if (id == null) return null;
        // 这里可以加个判断，如果数据已经被标记为sent，跳过（避免并发修改）
        YourEntity entity = yourEntityRepository.findById(id).orElse(null);
        return entity != null && !entity.isSent() ? entity : null;
    }
};

这种方式的优势是分页逻辑完全不受数据库数据变化影响，缺点是如果未发送数据量极大，预取所有ID会占用较多内存，此时可以分批预取ID（比如每次取1000个，处理完再取下一批）。

4. 按字段分区处理（Partitioning） #

如果数据量极大且需要并行处理，可以用Spring Batch的分区功能，按某个字段（如ID范围）将数据分成多个分片，每个分片独立处理。每个分片的查询基于范围而非offset，不会出现分页偏移问题。

实现思路： #

• 配置PartitionStep，自定义Partitioner按ID范围分片（比如每10000个ID为一个分片）；
• 每个分片的Reader查询该范围内的未发送数据：findBySentFalseAndIdBetween(Long startId, Long endId)；
• 多个分片并行处理，互不干扰。

内容的提问来源于stack exchange，提问作者Mançaux Pierre-Alexandre