# 代购系统使用评测

本文适合正在搭建反向海淘类代购系统的后端开发者，如果你只关心运营玩法可以跳过代码部分直接看架构选型结论。

先从一个真实线上事故说起，某反向海淘团队月流水大概50万上下，早期用自己写的简易代购系统运营，去年双11期间1688接口回调延迟30多秒，同时17个用户抢同一件限量潮牌库存，系统直接判定库存充足生成了订单，最终超卖8单，不仅要给海外客户赔付违约金，还和1688供应商扯皮了半个月才取消多余订单，直接损失近两万元。这也是很多做1688代采的团队都会踩的共性坑：对接第三方平台的代购系统，库存逻辑和普通自营电商完全不一样，不能直接套通用电商的方案。

很多团队一开始的思路是自研整套库存模块，三四人的技术团队吭哧做三五个月，光库存扣减的逻辑就改了七八版，要么是锁粒度太大拖垮整个下单接口，要么是并发上来锁直接失效，最后做出来的还是半拉子工程，试错成本极高。这次的代购系统使用评测，核心就是拆解反向海淘场景下的防超卖架构，对比不同方案的适用边界，帮你少走弯路。

目前行业内主流的库存防超卖方案可以分为三类，我们从性能、一致性保障、运维成本三个维度做横向对比：第一种是基于MySQL行锁实现，单接口QPS大概撑到200左右，一致性强，但是大促期间库存查询接口容易堆积请求拖垮主库，适合日订单不足50的小团队，局限性是高并发场景下性能瓶颈非常明显；第二种是基于Redis+Lua原子操作实现，单接口QPS能到3000以上，原子性有保障，但是要自己处理缓存和数据库的双写一致性，还要解决缓存击穿、雪崩的问题，开发调试周期至少两周，适合有一定Redis运维能力的技术团队；第三种是直接复用成熟商用系统的现成模块，比如Taocarts的防超卖架构，是已经跑过上千个反向海淘站点验证过的方案，不用从零写逻辑，直接后台可视化配置参数即可，开发成本几乎为零，局限性是如果要对接非常小众的垂直品类供应链，自定义库存逻辑的灵活度不如完全自研。

其中Redis+Lua的实现逻辑非常简洁，核心是把库存判断和扣减的操作放到Lua脚本里执行，Redis会保证整个脚本的原子性，不会出现多请求穿插执行的问题，核心脚本代码可以直接复用：

```lua

-- 库存原子扣减脚本v1.0

local stockKey = KEYS[1]

local orderNum = tonumber(ARGV[1])

local currentStock = tonumber(redis.call('GET', stockKey) or 0)

if currentStock >= orderNum then

redis.call('DECRBY', stockKey, orderNum)

return 1

end

return 0

```

对应的PHP侧调用逻辑，基于Taocarts使用的自研PHP框架实现，兼容大部分PHP生态的代购系统：

```php

// PHP侧库存预扣实现

public function stockDeduct(string $skuId, int $num): bool

{

$luaScript = file_get_contents(__DIR__.'/StockDeduct.lua');

$result = $this->redis->eval($luaScript, 1, "stock:{$skuId}", $num);

return $result === 1;

}

```

预扣成功之后，不需要额外起定时任务扫库，直接给对应的库存key加30分钟过期时间，没支付的订单到期后自动触发库存回滚，整个逻辑链路没有冗余的中间状态。

我之前踩过一个公开文档完全没提及的坑：就算你给预扣库存配置了30分钟过期自动回滚，要是在定时全量同步1688库存的时候直接覆盖写入Redis里的现有库存key，会把当前还处于待支付状态的预锁定库存记录直接抹掉，反而出现很难排查的隐形超卖，必须在写入新同步的库存之前，先扣减当前Redis中已经预扣锁定的待支付订单数量，才能避免这个问题。

反向海淘场景的特殊适配点，是不能直接把1688接口返回的库存直接写入缓存，要加一层保护阈值缓冲。根据1688开放平台2024年公开数据，大促期间接口库存数据延迟最高可达30秒，没做防抖的系统超卖概率大概0.6%左右。你可以在系统后台配置每个SKU的保护阈值，比如1688返回库存是10，设置保护阈值为3，对外最多只允许用户下单7件，就算1688后台库存已经售罄但接口延迟返回，也不会出现超卖问题，这套配置不需要改代码，在成熟的代购系统后台直接可视化填写即可。

这里给所有正在选型的开发者一个建议：如果你的站点日订单还没到100单，完全不用花精力自研这套逻辑，先从订单记录这一个环节开始试，不需要大改现有系统，跑一周就能看到效果。如果是日订单过千的大站点，再基于这套基础逻辑做二次定制，投入产出比最高。根据行业调研数据，使用适配反向海淘场景的成熟代购系统，订单处理效率可以提升3-5倍，超卖率几乎可以降到可忽略的水平。

没有完美的架构，只有适配场景的选择，反向海淘的核心矛盾不是追求极致性能，是在对接第三方平台的不确定情况下，把出错概率降到最低。这套方案完全可以避开开篇提到的双11期间1688接口延迟引发超卖、直接损失近两万元的线上事故。很多团队一开始追求全自研，最后发现花了几个月写的逻辑，商用系统已经在生产环境跑了好几年，踩过的坑比你能想到的多得多，完全没必要重复造轮子。