猫拽智库
结论先行：数据同步的本质就四步：定时拉取、增量识别、字段映射、冲突处理。增量识别在时间戳（简单、分钟级延迟）和 CDC（Change Data Capture，变更数据捕获，实时、需要数据库日志权限）之间二选一，中小企业 90% 的场景用时间戳增量就够了。按本文的四步法，多数同步任务用低代码工作流零代码即可完成。
电商订单在店铺后台，库存记在进销存，会员存在 CRM——每套系统都好用，数据却各管一段。业务人员每天手动导表粘贴，既慢又错。数据同步自动化就是把这些搬运工作交给系统，本文用四步法把这件事讲透。
一、四步法总览
这套流程在数据领域叫 ETL（Extract-Transform-Load，抽取-转换-加载），四步法是它的轻量版：
- 定时拉取：按固定频率从源系统取数（拉模式），或接收对方推送（推模式，即 Webhook）
- 增量识别：只处理上次同步之后变化的数据，避免每次全量搬运
- 字段映射：把源系统的字段名、格式、枚举值转换成目标系统的口径
- 冲突处理：同一数据两边都改过时，按预设规则决定以谁为准
四步都做对了，同步任务就稳了；任何一步偷懒，后面都是无尽的修数。
二、增量识别：时间戳 vs CDC
| 对比项 | 时间戳增量 | CDC 变更数据捕获 |
|---|---|---|
| 原理 | 按"更新时间 > 上次游标"查询 | 读取数据库日志捕获每笔变更 |
| 实时性 | 取决于同步频率，分钟级 | 秒级近实时 |
| 实现成本 | 低，加一个时间戳索引即可 | 高，需日志解析组件与权限 |
| 删除感知 | 需软删除标记配合 | 天然感知删除事件 |
选型建议：源系统是自家数据库且要求秒级一致，上 CDC；源系统是第三方平台接口（电商、支付平台），只能用时间戳增量。时间戳方案有个前提：表里必须有可靠的"更新时间"字段，任何绕过该字段的数据修改都会漏同步。
三、冲突策略：以谁为准
两边都可能改数据时，先定规则再动手。三种常用策略：最后写入优先（Last Write Wins，按修改时间晚者胜）适合简单场景；源系统优先（主数据所属系统说了算，如商品资料以 ERP 为准）适合有明确主数据的场景；冲突转人工（进差异队列人工裁决）适合金额、库存等关键数据。新旧系统并行期两套系统同时写入时，这类冲突还要进人工裁决队列，机制设计见新旧系统并行期方案。
一个高频的坑是删除同步：直接物理删除目标数据风险极大，正确做法是同步"软删除"标记，目标侧标记失效但不删记录，误同步可随时恢复。
四、实战：电商订单同步到进销存
以猫拽低代码（CatPull）为例，整条链路用工作流节点搭建：定时触发器每 15 分钟启动同步流；HTTP 请求节点调用电商平台接口，拉取"更新时间晚于上次游标"的新订单；循环执行节点逐单处理；云函数代码节点做字段映射（平台 SKU 对应物料编码、收货地址拆省市）；变量赋值节点更新同步游标；条件分支识别"库存不足"时自动触发补货提醒。失败分支统一进告警通知，支持从断点重跑。
设计上的三条经验：游标存到数据库而不是内存，服务重启不丢；每批拉取限量（如 200 条），避免大响应超时；同步日志按批次留痕，哪一批出了问题一目了然。
数据同步做好之后还有意外收获：同步链路沉淀的字段映射表和接口配置，就是企业数据资产的底账，后续做报表和数据分析时直接复用。要把这些底账变成每天能看的经营报表，还需要数据源接入、报表设计与权限分发这一层设计，报表系统怎么开发 对此有完整拆解。
FAQs
Q1：同步频率设多少合适？
A：按业务时效要求定：库存、订单类 5~15 分钟一次；对账类每天一次；主数据（商品、客户）每小时或每天一次。频率越高对接口压力越大，先从低频开始，业务方提出明确时效需求再加密。
Q2：两边同时改了同一条数据怎么办？
A：这就是冲突策略要解决的问题。推荐"主数据所属系统优先"：给每类数据指定唯一权威源（如库存以进销存为准、客户资料以 CRM 为准），非权威源只读或打冲突标记转人工，不要两边都能随便改。
Q3：零代码方案的性能上限在哪？
A：日均几万条以内的增量同步，低代码工作流完全胜任；日均百万条或要求秒级实时，应引入专业 ETL 工具或消息队列。低代码方案的优势是搭建快、可视化、好维护，先满足当下规模，量上来再升级链路。
延伸阅读
- 定时任务自动化设计：对账、提醒与数据同步——定时驱动的健壮性四件套
- 低代码平台的 API 集成策略：怎么打通 ERP、财务与 CRM——集成层的架构策略
- 数据库入门教程——时间戳、索引等基础概念
- 库存管理系统开发——库存同步的业务场景底座
