Gin 本身不解决超卖，关键在 Redis 操作是否原子：DECR 仅保证单命令原子性，但需配合返回值校验；Lua 脚本才能真正实现“查-判-扣”整体原子化，杜绝超卖。
直接说结论：Gin 本身不解决超卖，关键在 Redis 操作是否原子。用 DECR 或 Lua 脚本才是核心，Gin 只负责把请求稳稳接住、转发、返回。
为什么 synchronized 或 mutex 在 Gin 里完全无效
很多人一上来就写 sync.Mutex 包一层库存扣减逻辑，结果压测照样超卖——因为 Gin 默认是多 goroutine 处理请求，而 sync.Mutex 只在单个进程内有效。一旦服务横向扩容到多个实例，锁就彻底失效。
常见错误现象：
- 单机部署时看似正常，上线集群后超卖率飙升
- 日志显示“库存为 1”，但连续两个请求都返回 success
- 根本原因：锁作用域仅限当前进程，跨实例无共享状态
- Redis 是唯一被所有实例共同信任的“仲裁者”，必须依赖它做协调
- 别试图用 Go 的并发原语替代分布式协调，方向错了
DECR 命令能防超卖？前提是你得先存对值
DECR 确实原子，但它只对整数生效，且不会拒绝负数。如果初始库存是字符串 "10"，DECR 会报错 (error) ERR value is not an integer or out of range；如果库存已为 0，DECR 还会变成 -1，等于没拦住。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 初始化库存必须用
SET stock:1001 100（整数类型），不是SET stock:1001 "100" - 扣减前不用
GET再判断——那是非原子的两步操作，必然竞态 - 直接
DECR stock:1001，然后检查返回值：
✓ 返回 ≥ 0 → 扣减成功
✗ 返回 -1 → 库存已耗尽，需回滚业务逻辑（比如发 MQ 补单失败）
更稳的方案：用 Lua 脚本封装“查+扣”原子逻辑
单纯 DECR 无法处理“扣完要记录订单 ID”或“扣减量 > 1”等场景。EVAL 执行 Lua 是目前最通用、最可控的方式，Redis 单线程保证脚本内全部指令串行执行。
示例脚本（扣减指定数量并记录操作者）：
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock or stock < tonumber(ARGV[1]) then
return 0 -- 库存不足
end
redis.call('DECRBY', KEYS[1], ARGV[1])
redis.call('SADD', KEYS[2], ARGV[2]) -- 记录 buyer_id 到集合
return 1Go 中调用方式：
script := redis.NewScript(luaScript)
result, err := script.Run(ctx, rdb, []string{"stock:1001", "buyers:1001"}, "2", "user_abc").Result()
// result == int64(1) 表示成功- KEYS 和 ARGV 必须严格区分：KEYS 是 Redis key 名（会被 cluster 路由校验），ARGV 是纯参数
- 脚本里不能用
redis.call('SET', ...)替代DECRBY，否则失去原子性保障 - 注意 Lua 中数字比较默认是浮点，
tonumber()强转避免类型歧义
Gin 中怎么组织这个流程才不拖慢吞吐
高并发下，瓶颈常不在 Redis，而在 Gin handler 里混杂了日志、DB 写入、MQ 发送等同步操作。一个请求卡住 50ms，QPS 就断崖下跌。
- Redis 扣减必须放在 handler 最前头，且只做必要判断（成功/失败），不做任何额外 IO
- 订单生成、用户积分更新、通知推送等，全部扔进异步任务（如
go func() { ... }()或消息队列） - HTTP 响应体越简单越好，例如只返回
{"code":0,"msg":"ok"}，别塞订单详情 - 给 Redis 客户端配置合理超时：
ReadTimeout: 100 * time.Millisecond，避免一个慢请求拖垮整个连接池
真正容易被忽略的点：Lua 脚本里没做幂等校验。同一用户重复提交，脚本会反复扣减。必须在脚本开头加 HEXISTS 或 SISMEMBER 判断该用户是否已参与，否则“防超卖”反而引发“少卖”。
