伊兹密尔阿尔桑贾克的4家分店döner连锁店同时连接Getir Yemek、Trendyol GO和Yemeksepeti。他们不再维护三份独立菜单,而是把thMenu当作主记录;库存扣减集中发生,webhook扇出同时推送到三个平台。
主记录架构
D1_MENU表的products.stock_quantity是唯一规范来源。订单确认时执行原子UPDATE:UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0。0行受影响=售罄。
成功后事件推送到Cloudflare Queue。三个worker并行PATCH各平台API。平均扇出延迟340毫秒。
冲突解决
场景:库存5份lahmacun。同一秒从三个平台接到5个订单。原子UPDATE串行化它们——最后一个发现0而被拒绝。最终状态0,三个"售罄"信号扇出。
D1没有显式行锁,但WHERE stock > 0起到同样作用。6个月零超卖事件。
漂移对账
Yemeksepeti的webhook有30秒延迟,Trendyol即时,Getir每5秒轮询。每小时cron把三方与主记录比对。
- Yemeksepeti 5,Getir 3:主记录设为5,PATCH Getir
- 主记录0,平台2:立即PATCH 0
- 漂移>3:Slack告警
常见问题
每个平台都要手动输入菜单吗?不需要,主记录+扇出全部自动化。
竞争条件下谁优先?按timestamp FIFO,败者返回422。
cron是手动的吗?不,Workers上每小时自动,大漂移时Slack告警。
觉得有用?分享给朋友。