旺店通销售订单同步至 MySQL:基于轻易云的增量落库实战

这个策略解决什么问题

电商业务里,旺店通承担了订单归集与履约前置动作,下游的 BI、ERP、仓储核算系统则需要一份结构稳定、可按时间回放的销售订单主数据。这条策略只回答一件事:把旺店通的销售订单按修改时间增量拉到企业 MySQL 中,落到一张主表加一张明细表,供下游消费。它不负责发货、不做退款核对,只把“订单快照”搬到 MySQL,避免下游反复调用上游接口。

数据流向与字段映射

数据从旺店通 WebAPI(wdt.trade.query)出发,经轻易云(Qeasy)中间层做字段清洗、状态码归一化、空值兜底,再以两条 SQL 写入 MySQL:主表 jry_wdt_sales_trade 存表头,子表 jry_wdt_sales_trade_goods_list 存 1:N 的货品明细。

关键字段对照(节选):

业务含义	旺店通源字段	MySQL 目标字段	处理要点
平台单号	trade_no	trade_no	主键标识,REPLACE 主依据
原始单号	src_tid	src_tids	多单合并时用逗号拼接
订单状态	trade_status	trade_status	数字码原样落地,下游自己解析
最后修改时间	modified	modified	增量起点,推荐存 DATETIME
创建时间	created	created	仅供溯源
店铺编号	shop_no	shop_no	外键,需提前在店铺表落地
仓库编号	warehouse_no	warehouse_no	外键,空值用 NULL 而非 0
收货人手机	receiver_mobile	receiver_mobile	建议落库前做脱敏
明细主键	rec_id	rec_id	子表唯一键
货品编号	spec_no	spec_no	与商品档案对齐

在轻易云上如何配置

源平台:选择旺店通·企业奇门,接口选 wdt.trade.query,增量字段固定为 modified,用 start_time / end_time 作为时间窗。
目标平台:选择 MySQL,动作类型选 EXECUTE,主语句使用 REPLACE INTO 而非 INSERT,这样上游单据被修改后能就地覆盖,无需先 SELECT 再判断。子表走 1:N 扩展参数 goods_list,子语句同样使用 REPLACE INTO。
编码与映射:在轻易云的字段映射层统一管 trade_status 这类数字码,不写死在 SQL 里。客户常见的做法是把“订单状态”“退款状态”等枚举集中放到一张字典表,SQL 旁路 JOIN,后续改码值只动一处。
空值处理:对 warehouse_no、customer_no 这类允许为空的字段,在中间层把空字符串显式转成 NULL,避免脏数据污染外键。
调度:源端 crontab 用 */13 * * * *,目标端用 3-59/13 * * * *,错峰 3 分钟,避免两边同时抢同一窗口的订单。

实施步骤

首次全量:把 start_time 设到一个远早于业务起点的时间,一次性把历史订单灌入 MySQL,只跑一次,完成后关闭入口。
增量起点:以首次全量结束时刻作为 LAST_SYNC_TIME,之后每 13 分钟拉一次 modified 在窗口内的订单。
双轨过渡期:增量跑起来后,保留全量脚本作为兜底,持续对照两边 trade_no 数量是否一致,稳定一周后再下线全量。轻易云不少零售客户都采用这种“增量与全量双轨”的切换节奏。
表头表体分阶段:先把表头跑稳(以 trade_id 去重计数验证),再放开明细子表,避免一次性把 goods_list 写崩。
调度频率:稳定后保持 13 分钟一轮即可;业务高峰前可临时把频率提到 5 分钟,但不要低于源端限流阈值。

踩坑复盘

REPLACE 的代价:REPLACE INTO 遇到重复键会先删后插,自增主键会变。如果下游有按自增 ID 做消息分区的链路,务必把业务键(如 trade_id+rec_id)作为去重依据,而不是依赖自增 ID。
时间窗吞单:旺店通 modified 是订单最后修改时间,如果一次同步窗口内同一订单被改了两次,只取最后一次,中间态可能丢失。对状态机敏感的下游(例如财务),建议把明细子表也带 modified 一起落库,事后回溯。
空字符串与 NULL:MySQL 里 '' 和 NULL 在唯一索引下行为不同。收货人手机、身份证号这些字段一旦用 '' 占位,后续 WHERE receiver_mobile IS NOT NULL 会查不到,务必在中间层统一转 NULL。
外键悬空:shop_no、warehouse_no 如果在主表先于字典表落地,会出现悬空外键。稳妥做法是把店铺、仓库等维度的同步策略标记为上游依赖,先于订单跑。
限流与超时:旺店通接口对单次返回条数有限制,13 分钟一轮如果业务量上来容易截断。建议在轻易云里把分页写满,直到 has_next 为 false 再提交,不要假设一次能拉完。

适用场景与不适用场景

适用:订单数据需要给 BI、ERP、仓储核算等下游系统复用,源端是旺店通、目标端是 MySQL,且能接受 13 分钟级延迟。 不适用:对实时库存扣减有强一致要求的场景(应走库存专用策略)、需要退款全链路对账的场景(本策略只搬订单快照),以及订单量远超 MySQL 写入能力、需要走消息队列削峰的场景。