/tags/data-sync/ Recent content in data-sync on Hugo -- gohugo.io en Tue, 29 Sep 2026 13:38:09 +0800 /posts/global-product-information-management-architecture/ Tue, 29 Sep 2026 13:38:09 +0800 /posts/global-product-information-management-architecture/ 当一个电商系统只在一个国家或一个机房跑时，商品数据往往只需要一张简单的 items 或 spu 表加上几张关联表就能支撑。运营录入标题、价格和库存，买家在前台浏览下单，结构非常直接。 业务扩到多个国家和大区以后，同一套商品数据要同时应付几件事： 同一件冲锋衣，美东站卖 120 美元配英文详情，巴西站卖 600 雷亚尔配葡语详情；沙特站的受监管商品还要先在 SABER 平台拿到符合性证书，海关才放行（见美国商务部 trade.gov 的说明，2018-09-18）。 服装关心尺码和面料，数码产品关心芯片和电池，食品要标保质期和过敏原。每类参数都在老表上加一列，表会越来越宽，字段含义互相打架。 大区离中心远。Azure 公布的区域间往返延迟（P50，2026-07-30 结束的 30 天数据）里，美东到东南亚是 224 毫秒（见 Azure network round-trip latency statistics），页面请求没法每次都跨洋读中心库。 发到各大区的数据要是审核过的完整版本，分发途中还会遇到重复投递、乱序和绕过管道的手工改库。 大促时，商品详情页（PDP）的读请求集中打在各个大区。 解决思路是把职责分到中心和大区两边。中心是一套 PIM（Product Information Management，商品信息管理）加 MDM（Master Data Management，主数据管理）的系统，作为企业商品数据的单一事实源（Single Source of Truth），负责定义商品、审核和发布，Zalando 自研的 Smart Product Platform 就是这两者的组合。各个大区保存只读副本，就近服务读请求。 整体架构 flowchart LR subgraph Center["中心：PIM / MDM"] BO["运营后台草稿、审核、打版"] --> DB[("中心库版本快照 + outbox 表")] end DB -->|"Debezium 读 binlog"| K["Kafka按 spu_id 分区"] K --> AG["大区同步代理按版本号幂等写入"] AG --> RDB[("