代购客户管理的技术底座：从积分体系到库存预扣
“深夜十一点，客户发来消息：'我明明抢到了限量款，为什么订单被取消了？' 后台日志显示，同一时间有四十多人同时提交了同一款商品的订单，而库存只有三十件。系统按支付顺序扣库存，但支付回调延迟了十几秒，导致支付成功的人数超过了实际库存。”
这个场景在代购客户管理系统中反复出现。客户管理不只是记录联系方式、发发优惠券，它的技术底座是订单履约的可靠性——客户信任你，下了单，你就得保证不超卖、不重复扣款、积分不丢失。而这些，都指向同一个问题：高并发下的状态一致性。
客户权益的载体：积分与等级的状态机
代购客户管理通常包含会员等级、积分、优惠券三个核心模块。看似简单的加减积分，在高并发下很容易出问题。比如客户下单返积分，如果下单接口被重复调用（网络重试、前端按钮重复点击），积分就可能被重复增加。
积分操作的幂等性，靠的是业务流水号 + 唯一索引。每次积分变动生成一个serial_no（格式：{user_id}_{timestamp}_{rand}），写入积分明细表时利用数据库唯一约束防重。
CREATE TABLE credit_log (
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
serial_no VARCHAR(64) NOT NULL UNIQUE, -- 幂等键
amount DECIMAL(10,2) NOT NULL,
order_id INT,
created_at DATETIME
);
等级升级则依赖状态机。等级变更条件（如累计消费达某个阈值）可能被多个事件触发（订单支付成功、退款、手动调整），必须用乐观锁防止重复升级：
UPDATE users SET level = 'gold', updated_at = NOW()
WHERE user_id = ? AND level = 'silver';
库存预扣：客户信任的第一道防线
代购客户管理系统中最影响体验的不是积分少加一分，而是“付款成功告诉我没货”。解决思路是预扣库存 + 异步确认。客户点击“提交订单”时，不是直接扣减真实库存，而是先扣一个“虚拟库存”（可售库存上限）。
用 Redis Lua 脚本保证原子性：
-- 预扣虚拟库存，返回1表示成功，0表示库存不足
local key = KEYS[1]
local stock = tonumber(redis.call('get', key) or 0)
if stock > 0 then
redis.call('decr', key)
return 1
end
return 0
预扣成功后创建订单，状态为“待支付”。支付成功后，再异步去扣减1688或自营仓的真实库存。如果支付超时（比如15分钟未支付），虚拟库存需要回滚。回滚操作同样用Lua脚本，并且要记录回滚流水，防止重复回滚。
这里有个隐性知识点：虚拟库存的阈值不能设为真实库存的。因为1688库存有延迟，可能下单时显示有货，实际支付时已卖完。安全做法是设置一个缓冲系数（比如0.9），预留10%的缓冲。这个系数可以根据历史缺货率动态调整。
分布式锁：防止同一客户重复下单
除了库存，客户管理还要防止同一个客户对同一件商品短时间内重复下单（比如前端按钮连点）。这可以用 Redis 分布式锁，锁的粒度是 user_id + product_id。
$lockKey = "lock:order:{$userId}:{$productId}";
$locked = $redis->set($lockKey, 1, ['nx', 'ex' => 3]); // 锁3秒
if (!$locked) {
return ['code' => 429, 'msg' => '操作太频繁'];
}
// 执行业务逻辑
锁的超时时间不宜过长，否则会影响用户体验。同时要避免锁被误释放——释放时需校验锁的值是否为当前请求持有（用 UUID 作为锁值）。
隐性知识点：1688库存同步的“幽灵订单”
在代购场景中，1688平台的库存不是实时准确的。一个常见的踩坑：系统查询1688商品详情得到库存5件，客户下单支付后去1688下单，结果返回“库存不足”。这是因为在你查询和下单之间，有别的渠道买走了。
解决方案是不依赖1688的实时库存做预扣。客户下单时只校验本地虚拟库存，然后立即在1688那边创建一笔“待付款”订单（占用库存），再把支付链接给客户。客户支付成功后，再去1688完成支付。这样即使查询到下单之间有延迟，库存已经被锁住了。不过1688的“待付款锁库存”接口不是所有供应商都开放，需要根据实际情况降级。
回头来看，代购客户管理系统的技术深度，往往体现在这些看不见的边界处理上——积分幂等、库存预扣、分布式锁、外部库存锁定。taocarts 在客户管理模块的设计中，把这套预扣+锁+异步确认的链路封装成了可配置的规则引擎，让代购商家可以根据不同商品（高价值/低价值）选择不同的库存策略。而关于如何把这些客户数据转化成复购，我们下篇从营销自动化角度展开。
