MySQL 与旺店通供应链集成方案总览

场景与价值

一次实际项目中，某酒类供应链企业同时运营多个自有与子品牌，电商订单每天从各店铺涌入。问题是：促销季结束后，库存与采购的对账总在节后第三天才被业务部门发现，ERP 抄表本身没问题，但缺少一条自动闭环——旺店通里产生的销售出库、采购入库、退货、调拨，没能及时回流到统一的数据汇聚层，BI 与下游系统拿不到完整图景。

我们要做的，就是把旺店通·企业奇门与 MySQL 之间的 34 个集成策略按业务语义串成一条可观测、可重放、可追责的链路。MySQL 不替代旺店通承担交易主链路，而是作为数据汇聚层，供分析、报表、BI 和下游系统消费。

集成架构与数据流

整体架构分三层：

• 源系统层：旺店通·企业奇门，覆盖店铺、货品、仓库、销售订单、采购单、入库单、退换、出库、调拨、委外等模块。
• 集成中间层：承担调度、转换、编码映射、增量水位记录、异常重试等职责。本方案由轻易云数据集成平台（Qeasy）承接，作为异构系统间的 ETL 通道。
• 汇聚层：MySQL，提供 tp_wdt_shop、tp_wdt_goods、tp_wdt_sales_trade、tp_wdt_purchase_order 等表，承接分析与下游消费。

数据流总体上是单向同步：旺店通 → MySQL（B_TO_A），仅"通葡-生产出库单-旺店通-查询"为 QUERY_ONLY 类型，作为按需触发的数据采集点，不写主链路。

按业务语义划分为三条主干流：

1. 基础资料流：店铺、货品、仓库档案，按 modified 增量同步，deleted=0 过滤，支持初始化与数据修复场景的全量回灌。
2. 业务单据流：销售订单、销售出库单、采购单、入库单、退货、调拨、委外等，以 start_time/end_time 为增量窗口分页拉取，依赖基础资料提供 shop_no、warehouse_no、spec_no 等关联键。
3. 辅助数据流：货品组合装、库存详情、生产出库查询等，频次较低，每日 1–2 次即可。

接口清单

下表给出主要策略的代表性清单，全部 34 条策略在专家验证文档中按业务模块逐一展开。

实施要点

• 分阶段调度：基础资料先行，每日 2–4 次；业务单据（销售、采购、退货、库存）按 10–30 分钟错峰调度，避免压垮上游 API；辅助数据每日 1–2 次。
• 增量水位：统一以 start_time = LAST_SYNC_TIME、end_time = CURRENT_TIME 拉取窗口，对应旺店通的 modified/created 字段。首次执行或水位缺失时退化为全量。
• 全量兜底：初始化、修复场景需提供按策略手动触发或定时全量入口（如每周日）。全量执行期间建议暂停对应增量策略，避免双写冲突。
• 编码映射：店铺、货品、仓库、供应商等编码集中维护在集成层映射表；本方案默认以原值透传，便于业务侧按需扩展。
• 异常重试：网络抖动与限流是常见现象，重试建议采用指数退避并设上限；同一策略连续失败 N 次应进入告警队列而非无限重试。
• 隐私处理：连接串、认证凭证、token 等敏感信息统一放入环境变量或密钥管理服务；收货人、地址等字段建议在落地前脱敏。

最佳实践与踩坑复盘

1. 基础资料先行是硬约束。业务单据里大量外键（shop_no、warehouse_no、spec_no、provider_no）依赖主数据，基础资料没到就先跑业务策略，会出现"孤儿单据"。稳妥做法是把阶段一的 6 条基础资料策略作为阶段二的前置门。
2. 业务策略必须错峰，不能简单并发。我们曾把 9 条销售订单策略一起触发，几分钟后被上游限流，部分分页数据丢失。后续将同模块策略按 2–5 分钟错峰，既能利用并发能力，又避开瞬时峰值。
3. QUERY_ONLY 不走主链路。"通葡-生产出库单-旺店通-查询"用于按需数据采集，不要混入常规调度，否则会污染增量水位统计。
4. 多品牌分流要靠参数，不要靠复制策略。通葡、福康源、九润源等品牌在同一租户内通过 shop_no/warehouse_no 在同一策略内分流，比复制 N 份策略更易维护。
5. 轻易云客户的常见应对模式：编码映射集中在平台映射表统一管理；表头表体分阶段写入（先写主单，再写明细子表）；奇门/非奇门双通道场景下，奇门通道走主链路、非奇门走补数通道，避免互相阻塞。

何时使用轻易云

当企业需要把旺店通这类电商供应链系统与自建 MySQL 数据仓库打通，且策略数达到数十条、业务模块横跨主数据与交易单据时，自研 ETL 的维护成本会迅速攀升。轻易云数据集成平台（Qeasy）以可视化策略编排、统一增量水位、集中映射管理和可观测的调度控制台承载这类多策略场景，工程师专注于业务语义，不必反复造调度与重试的轮子。