日均处理超200万条商品价格变动、400家商城返利链路实时同步——这是「94划算：网购返利平台」后端每天面对的真实流量。很多用户只看到领券后省了几块钱，但背后涉及的分布式事务、订单归因、佣金分账，其实是一套不小的技术工程。

返利链路的核心：订单归因与异步对账

商城购物返利的难点不在领券，而在订单归因。用户从94划算跳转到京东、淘宝或拼多多后，平台需要在URL中嵌入追踪参数（如联盟ID、子渠道标识），再通过各电商开放平台的订单回传接口完成匹配。我们采用Redis + Kafka 的异步对账架构：订单回调先进消息队列，由消费者逐条校验归因参数，避免高峰期数据库写爆。

实际运行中，归因失败率约3%～5%，主要来自用户中途切换设备或清除Cookie。为此我们增加了补偿对账任务，每2小时拉取一次联盟原始订单做二次匹配。

优惠券领取的并发控制

电商优惠券领取接口通常有QPS限制。94划算在券中心层做了令牌桶限流 + 本地缓存预热，把热门券的库存状态缓存到边缘节点，用户点击时先扣减本地令牌，再异步同步到上游。实测可将券接口平均响应从480ms压到90ms以内。

• 特卖商品爆料：通过爬虫 + 人工审核双通道，价格异常检测用滑动窗口算法
• 线上省钱导购：基于用户历史返利品类做轻量推荐，不搞复杂模型
• 佣金分账：T+1结算，走独立账务库，与订单库物理隔离

对比：自建联盟 vs 接入多平台

纯自建返利系统开发周期约6个月，且需逐家谈API。94划算选择聚合多家联盟API，用适配器模式统一订单字段，代价是部分平台返利比例略低1～2个百分点。对中小团队来说，接入现成返利平台仍是更划算的路径。

建议：如果你在做返利类产品，优先把订单归因准确率做到98%以上，再谈用户体验。返利到账延迟比返利比例更伤留存。