TP6.0 如何处理高并发抢购?Redis 原子锁与队列削峰详解【秒杀】
高并发抢购中,Redis的DECR原子操作可安全扣库存;配合think-queue异步削峰,接口仅扣库存和推消息;分布式锁需用SETNXEX加唯一标识,释放时用Lua脚本校验;成功资格后须以数据库事务双写为准,失败时补回Redis库存。
在高并发抢购场景下,Redis的原子操作、队列削峰和分布式锁是三个绕不开的技术点。处理不好,轻则超卖,重则资损。我先说几个核心判断,后面再展开细聊。
DECR比“查+改”更安全,这几乎是行业共识。原因在于,DECR是单命令原子操作,Redis单线程串行执行,天然避免了高并发下读到相同旧值导致超卖的问题。而GET+SET这三步之间,存在一个时间窗口,哪怕只有毫秒级,也足以被数千并发请求击穿。DECR一步到位,连Lua脚本都不必写——除非你还需要附带额外的条件逻辑。
Redis DECR 原子减库存为什么比查+改更安全
DECR是单命令原子操作,不依赖中间状态。高并发下,多个请求同时执行“DECR stock:1001”,Redis内部会串行处理,结果必然准确递减,不会出现“读到1、都减成0、实际超卖”这种经典问题。
常见错误是先GET再判断再SET,这三步之间存在时间窗口,哪怕毫秒级也足以被数千并发击穿。而DECR一步到位,连Lua脚本都不必写(除非要附带条件逻辑)。
- 必须确保库存初始值为非负整数,且用INCR初始化,避免DECR返回负值后业务误判
- 返回值直接可用:
if ($redis->decr('stock:1001') >= 0) { /* 成功 */ }—— 注意:返回值是减后的值,不是是否成功布尔值 - 若需“减完立刻判断是否归零”,建议用EVAL执行Lua脚本封装逻辑,防止网络往返导致的竞态
TP6 中用 think-queue 实现异步下单队列削峰
抢购接口只做两件事:扣Redis库存 + 推消息进队列。真正写订单、扣款、发通知等耗时操作,全部丢给消费者异步处理。这样接口响应能压到20ms以内,扛住瞬时万级QPS。
ThinkPHP 6默认不带队列驱动,需手动安装并配置:
- 执行
composer require topthink/think-queue - 在
config/queue.php中启用Redis驱动,'default' => 'redis' - 抢购控制器中调用
Queue::push(),传入商品ID、用户ID、订单参数数组 - 单独起一个
php think queue:listen进程消费,避免和Web请求争抢资源
注意:队列消息体不要过大,推荐只传关键ID和签名,敏感数据如用户手机号、价格等应在消费时实时查库获取,防止消息泄露或过期失效。
setIfAbsent 分布式锁在 TP6 里怎么防重入和误删
TP6自带的 Cache::lock() 封装较浅,底层仍是 setIfAbsent,但默认没做线程标识校验,容易出现A拿锁、B误删、A继续执行的严重问题。
正确做法是手动构造带唯一标识的锁键,并在释放前严格校验:
- 锁键格式建议为
lock:seckill:1001:uid_12345,把用户ID融入键名,天然隔离不同用户请求 - 获取锁时用
$redis->set($key, $token, ['nx', 'ex' => 10]),其中$token是当前请求唯一字符串(如md5(uniqid().$userId)) - 释放锁必须用Lua脚本:
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:xxx token_xxx - 不要依赖
Cache::unlock(),它不校验token,纯靠key删除,极不安全
为什么秒杀后还要查数据库确认库存?
因为Redis是缓存,不是权威数据源。抢购成功只是“资格获得”,最终以MySQL订单表和库存表双写一致为准。否则一旦Redis故障或主从延迟,会出现“前端显示抢到了,后台没下单”的资损。
典型流程是:Redis扣成功 → 推队列 → 消费者执行事务:BEGIN; SELECT number FROM stock WHERE id=1001 FOR UPDATE; UPDATE stock SET number=number-1; INSERT INTO order(...); COMMIT;
- MySQL的
SELECT ... FOR UPDATE必须走主键或唯一索引,否则会锁全表,拖垮整个库 - TP6使用
Db::transaction()包裹时,务必捕获异常并回滚,否则锁可能一直挂着 - 如果MySQL写失败(如唯一键冲突、余额不足),需回调Redis补回库存:
INCR stock:1001,否则库存永久丢失
最易被忽略的是补库存这步——很多人只关注“抢到”,却没设计“抢失败后如何还原缓存”,导致后续所有请求都看到错误库存值。


































