decr比查+改更安全，因其是单命令原子操作，redis单线程串行执行，避免高并发下读到相同旧值导致超卖；而get+set存在时间窗口，易被击穿。
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，否则库存永久丢失
最易被忽略的是补库存这步 —— 很多人只关注“抢到”，却没设计“抢失败后如何还原缓存”，导致后续所有请求都看到错误库存值。
