4. 批量接口设计原则

在供应链数据集成中，批量接口是吞吐量的核心杠杆。设计不当的批量接口会导致数据库锁竞争加剧、内存溢出或网络超时。本节围绕三个关键维度展开：批量大小（Batch Size）的确定策略、分页与游标机制的实现方式、批量提交与事务边界控制的最佳实践。

4.1 批量大小（Batch Size）的确定策略

批量大小并非越大越好。过大的批次会长时间占用数据库连接和事务锁，过小的批次则增加网络往返次数。确定最优批量大小需要综合以下因素：

4.2 分页与游标机制

当数据源需要读取大量记录（如百万级订单、库存流水）时，一次性加载到内存不可行。分页和游标是两种主流的分批读取策略。

4.2.1 基于偏移量的分页（Offset-based Pagination）

使用 LIMIT offset, size 或 OFFSET … FETCH NEXT 语法。适用于数据量较小（< 10 万行）且数据变动不频繁的场景。

• 优点：实现简单，支持随机跳页。
• 缺点：深度分页时性能急剧下降（数据库需要扫描并丢弃前 offset 行）；数据在分页过程中发生插入/删除会导致结果不一致或重复。

4.2.2 基于游标的分页（Cursor-based Pagination / Keyset Pagination）

利用有序唯一键（如自增 ID、时间戳）作为游标，每次查询返回 WHERE id > last_id ORDER BY id LIMIT size。适用于大数据量、高并发写入的供应链场景。

• 优点：性能稳定，不受总行数影响；天然避免数据重复或遗漏。
• 缺点：不支持随机跳页；需要业务字段支持排序。

4.3 批量提交与事务边界控制

批量接口的事务边界决定了数据一致性与性能的平衡点。供应链集成中常见的三种模式如下：

4.3.1 分段提交的代码示例（Java + Spring + MyBatis）

public void batchInsertOrders(List<Order> orders, int chunkSize) {
    // 1. 按 chunkSize 拆分列表
    List<List<Order>> chunks = Lists.partition(orders, chunkSize);
    
    // 2. 逐段提交，每段独立事务
    for (List<Order> chunk : chunks) {
        try {
            // 开启新事务（REQUIRES_NEW 传播级别）
            transactionTemplate.execute(status -> {
                orderMapper.batchInsert(chunk);
                return null;
            });
        } catch (DataIntegrityViolationException e) {
            // 3. 幂等处理：跳过已存在的记录，记录失败日志
            log.warn("Chunk conflict, retrying with single insert: {}", e.getMessage());
            for (Order order : chunk) {
                retrySingleInsert(order);
            }
        }
    }
}

4.4 综合设计原则总结

• 动态调优：批量大小不应是静态常量，应通过压测和运行时指标（TPS、P99 延迟、DB 锁等待）动态调整。
• 游标优先：对于持续增长的供应链数据（订单、库存、物流），始终使用游标分页而非偏移量分页。
• 分段事务：默认采用分段提交模式，chunkSize 建议在 100~500 条之间，根据单条数据大小和数据库负载微调。
• 幂等设计：每个批量接口必须支持幂等重试，业务主键去重是供应链集成的基础保障。
• 监控告警：对批量接口的提交耗时、失败率、重试次数进行实时监控，超过阈值自动降级或熔断。