第4章数据同步策略

数据同步策略：实时同步与定时批量同步的优缺点及适用场景

好，咱们接着聊。ERP和WMS对接，数据怎么同步过去？这是个绕不开的核心问题。

我见过不少项目，一开始拍脑袋选了实时同步，结果上线第一天就把数据库搞崩了。也见过选了定时批量同步，结果库存数据对不上，财务那边炸了锅。说白了，没有银弹，只有最合适的方案。

今天我就把这两种策略掰开揉碎了讲。你听完，至少知道什么时候该选哪个。

实时同步：快，但有代价

实时同步，顾名思义，数据一发生变动，立刻推送到对方系统。比如WMS里扫了个条码入库，ERP那边库存数马上更新。

优点很明显：

数据一致性高——两边系统几乎实时对齐，不会出现「明明有货，系统显示没货」的尴尬。
业务响应快——拣货、发货、盘点，每一步都能立刻反映到ERP，适合高频操作场景。
减少人工干预——不需要等定时任务跑完，系统自己就搞定了。

缺点也扎心：

对系统压力大——每次操作都要发一次请求，高并发时接口扛不住。我遇到过一家电商大促，每秒几百个订单，实时同步直接把ERP搞挂了。
网络依赖强——网络一抖，数据就丢了或者重复了。你得自己写重试、幂等、补偿机制。
调试困难——出了问题，你得从海量日志里找是哪一秒哪条数据没同步过去。嗯，那感觉就像大海捞针。

适用场景：

库存实时查询要求高的场景（比如电商、门店调拨）
操作频率低、并发小的系统（比如传统制造业的出入库）
对数据一致性要求极高的场景（比如财务对账、批次追溯）

定时批量同步：稳，但有延迟

定时批量同步，就是每隔一段时间（比如5分钟、1小时、每天凌晨），把WMS的数据打包推给ERP。或者反过来，ERP把主数据推给WMS。

优点：

系统压力小——数据攒一批再发，数据库和网络都轻松。我做过一个项目，每天凌晨2点跑一次批量同步，白天系统几乎零负担。
容错性好——一次失败了可以重试整个批次，不用一条一条去补。
实现简单——写个定时任务，查个表，拼个JSON，POST过去就完事了。比实时同步少写一堆补偿逻辑。

缺点：

数据有延迟——这是硬伤。你想想，WMS已经出库了，但ERP那边库存还没扣，这时候有人下单，就可能超卖。
批量冲突风险——如果两个系统同时修改同一条数据，批次同步时可能覆盖掉对方的修改。我吃过这个亏，后来加了版本号才解决。
不适合高频场景——比如流水线每分钟出几百个货，你等5分钟才同步一次，那中间这段时间数据就是错的。

适用场景：

对实时性要求不高的场景（比如月结、财务对账、报表统计）
数据量大、并发高的场景（比如大型仓库的批量入库）
网络不稳定或系统资源有限的环境（比如工厂内网、老旧系统）

怎么选？我给你个决策框架

你可能会问：「那我到底该用哪个？」

我个人习惯，先问三个问题：

数据延迟能接受多久？——如果超过1分钟就会出问题，那就别考虑定时了。
系统并发有多高？——如果每秒超过100次操作，实时同步大概率扛不住，得加消息队列或者限流。
业务场景是「操作型」还是「分析型」？——操作型（比如拣货、发货）需要实时，分析型（比如报表、对账）可以定时。

举个例子。我之前做过一个冷链仓储项目，WMS和ERP对接。冷藏库的出入库频率不高，但每次操作都涉及批次和保质期，数据错了会出大问题。我选了实时同步，但加了本地缓存和重试机制。结果上线后很稳，没出过数据不一致。

另一个项目是大型电商的中央仓库，每天几十万单。实时同步肯定不行，我用了定时批量同步，每5分钟一次。但为了防超卖，我在WMS里加了个「预占库存」的逻辑，下单时先锁库存，等批次同步时再正式扣减。这样既保证了性能，又避免了超卖。

我的建议：

别非黑即白。很多项目是混合策略——核心数据实时同步，非核心数据定时批量。比如库存数量实时同步，但历史记录、日志、报表数据每天批量同步一次。这样既保证了业务连续性，又减轻了系统压力。

代码示例：一个简单的定时批量同步任务

下面是我常用的一个定时任务伪代码，用Java写的，但思路通用。

// 定时任务，每5分钟执行一次
@Scheduled(cron = "0 */5 * * * ?")
public void syncInventoryBatch() {
    // 1. 查询上次同步时间
    Date lastSyncTime = getLastSyncTime("INVENTORY");
    
    // 2. 查询WMS中自上次同步以来有变动的数据
    List<InventoryChange> changes = wmsService.getChangesSince(lastSyncTime);
    
    if (changes.isEmpty()) {
        return; // 没变化，跳过
    }
    
    // 3. 组装成批量数据
    BatchPayload payload = new BatchPayload();
    payload.setChanges(changes);
    payload.setBatchId(UUID.randomUUID().toString());
    
    // 4. 调用ERP接口，带重试
    boolean success = false;
    int retryCount = 0;
    while (!success && retryCount < 3) {
        try {
            erpService.batchSync(payload);
            success = true;
        } catch (Exception e) {
            retryCount++;
            log.warn("批量同步失败，第{}次重试", retryCount);
            Thread.sleep(1000 * retryCount); // 指数退避
        }
    }
    
    // 5. 更新同步时间戳
    if (success) {
        updateLastSyncTime("INVENTORY", new Date());
    } else {
        // 记录失败批次，人工介入
        alertService.sendAlert("库存批量同步失败，批次ID: " + payload.getBatchId());
    }
}

注意：

定时批量同步最怕「重复数据」和「漏数据」。我建议你在每次同步时带上批次ID和版本号，ERP那边做幂等处理。另外，别忘了记录同步日志，方便排查问题。我曾经因为没记日志，花了三天才找到一条数据没同步的原因——原来是时间戳精度不够，毫秒级的数据被漏掉了。

总结一下

实时同步和定时批量同步，没有谁比谁高级。关键看你的业务场景。

实时同步适合「快、准、少」的场景——快响应、准数据、少并发。
定时批量同步适合「稳、大、慢」的场景——稳运行、大数据、慢变化。

你想想看，你的项目属于哪种？如果还不确定，我建议你先做个小范围的压测，看看实时同步能不能扛住。扛不住就切定时，或者上消息队列做异步实时同步。嗯，这个我们后面章节会细讲。

好，今天就到这儿。下一章我们聊聊数据冲突怎么处理——这可是个坑，我踩过好几次。