秒杀排队不能只靠前端按钮禁用，因真实压力来自后端并发请求；需在入口层用redis list+lua原子入队，解耦排队与执行，避免打穿数据库或服务假死。
秒杀排队为什么不能只靠前端按钮禁用
前端禁用按钮只是障眼法，真实压力来自后端并发请求。用户绕过 JS、用脚本批量发请求、网络重试都会让流量瞬间击穿服务。Gin 本身不带排队逻辑，必须在请求入口层主动缓冲和节制。
核心矛盾是：MySQL 写入吞吐有限（尤其库存扣减+订单生成），而瞬时 QPS 可能上千。不排队，直接打穿数据库连接池或产生超卖；排错队，又可能把用户卡在中间件里耗尽内存。
- 单纯用
c.Abort()拒绝请求 → 用户立刻看到 429，体验差，且没解决“谁该进、谁该等”的问题 - 用全局 channel 做 FIFO 队列 → 并发高时 channel 阻塞导致 Gin worker 卡死，整个服务假死
- 在数据库层加 SELECT FOR UPDATE → 行锁竞争激烈，事务等待超时频发，错误率飙升
用 Redis List + Lua 实现原子排队与出队
真正可用的排队机制，得把“排队”和“执行”解耦：请求先写入 Redis 队列，再由后台 goroutine 消费。这样 Gin handler 能快速返回（如“已进入排队，预计 3 秒后处理”），不阻塞 HTTP 连接。
关键点在于入队必须原子——避免多个请求同时判断“队列长度 LPUSH + LLEN + Lua 脚本组合：
local queue_key = KEYS[1]
local max_len = tonumber(ARGV[1])
local current_len = redis.call("LLEN", queue_key)
if current_len
<p>在 Gin 中调用：</p>
<pre class="brush:php;toolbar:false;">res, err := rdb.Eval(ctx, luaScript, []string{"seckill:queue:1001"}, "1000", payload).Int()
if err != nil || res == 0 {
c.JSON(429, gin.H{"msg": "排队人数已满"})
return
}
-
seckill:queue:1001是商品维度队列，避免所有秒杀挤一个队列 - max_len 设为 5000 比较稳妥：Redis List 千级长度性能无压力，再往上需分片
- payload 应包含用户 ID、商品 ID、时间戳，供消费端校验幂等性和超时
消费端如何防止重复扣库存和超时漏单
消费 goroutine 不是简单从 BRPOP 取数据就完事。必须兼顾三件事：去重、防重放、兜底超时。
典型结构是「Redis Hash 记录已处理 ID + Set 记录当前处理中 ID + 定时扫描超时任务」：
- 每次取到消息，先
SADD seckill:processing:1001 <req_id></req_id>，失败则跳过（说明已在处理） - 扣库存前，
HSETNX seckill:deducted:1001 <req_id> 1</req_id>，确保同一请求只扣一次 - 设置消息 TTL（如 30s），用
EXPIRE配合消费逻辑；超时未完成的，由定时任务扫seckill:processing:*清理并补偿 - 消费失败不要丢弃消息，应
LPUSH回原队列尾部，并加重试计数（避免无限循环）
Gin 中如何返回实时排队位置和预估等待时间
用户需要感知“我在哪一队、还要等多久”，这要求队列长度可查、处理速率可估。别用 LLEN 实时算——高并发下频繁读队列长度会拖慢 Redis。
更可行的是维护两个 Redis key：
-
seckill:queue:len:1001：用INCRBY/DECRBY原子更新，代表当前排队人数（比LLEN快 10 倍） -
seckill:queue:tps:1001：每秒消费数，由消费端每秒INCR一个计数器，TTL 设为 5s，读时取最近 3 个值平均
返回给前端：
c.JSON(200, gin.H{
"status": "queued",
"position": rdb.Get(ctx, "seckill:queue:len:1001").Val(),
"estimated_wait_sec": int64(atoi(rdb.Get(ctx, "seckill:queue:len:1001").Val()) /
atoi(rdb.Get(ctx, "seckill:queue:tps:1001").Val())),
})
注意：estimated_wait_sec 是粗略值，实际要加 buffer（比如 +2s），避免用户刚看到“1s”就刷新页面，发现变“3s”而焦虑。
真正的难点不在代码怎么写，而在压测时发现 Redis 队列长度统计和实际消费进度不同步——因为 INCR/DECR 和 BRPOP 不在同一个事务里。必须接受这种最终一致性，靠监控告警和人工兜底来覆盖那 0.1% 的偏差。
