Golang结合Redis实现秒杀系统逻辑

本文深入剖析了使用Golang结合Redis构建高并发秒杀系统的核心实践，强调Redis的DECR命令是唯一能可靠应对瞬时洪峰的库存扣减方案，必须严格校验其返回值以实现精准库存控制与自动回滚；同时指出幂等下单必须依赖SETNX设计业务维度的唯一键，彻底摒弃本地缓存和数据库唯一索引等低效或失效方案；更关键的是，channel限流容量需通过压测科学确定而非经验估算，并将限流逻辑统一收口于Gin中间件，避免资源超载引发Redis延迟飙升、MySQL排队乃至OOM崩溃——每一条都是历经真实流量淬炼出的硬核避坑指南。

Redis.Decr 是唯一能扛住瞬时洪峰的库存扣减方式，写两行 SQL 或用 MySQL 行锁都撑不住真实秒杀流量。

redis.Decr 必须校验返回值并立刻回滚

DECR 不是“执行扣减”就完事了，它返回的是扣减后的数值。不检查这个值，等于把库存交给运气。

• 返回 redis.Nil：说明 key 不存在，可能是活动未开始或配置漏了，不能 panic，得明确返回错误提示
• 返回值 redis.Incr 回滚，否则网络中断或 panic 会导致库存永久变负
• 返回值 ≥ 0：才是真正的成功，且该值就是剩余库存数，可用于前端展示或风控判断
• 别用 Lua 脚本封装 “GET + DECR”，这破坏原子性；正确脚本只做 DECR 并返回新值，由 Go 层统一校验

幂等下单必须用 SETNX，禁用本地缓存和数据库唯一索引

用户刷新、F5、脚本重放，会让同一个账号在毫秒内发多次请求。前端 disabled、JWT claim 标记、session 状态，全无效。

• key 必须设计为 seckill:order:{goodsID}:{userID}，含业务维度，避免跨场次污染
• value 存毫秒时间戳或随机 token，过期时间设为支付超时 + 30s（比如 15 分钟）
• redis.SetNX 返回 false 就直接返回 “您已参与本场秒杀”，不走任何后续逻辑
• 不能用 sync.Map 或本地 map：多实例部署下完全失效；也不能依赖 MySQL 唯一索引防重：写库太慢，洪峰一来 DB 直接排队甚至挂掉

channel 限流容量不是经验值，而是压测出来的生死线

make(chan struct{}, 100) 这个 100 不是拍脑袋定的，它直接决定 Redis 延迟、MySQL 排队、机器内存水位是否越界。

• 压测时盯紧 Redis INFO commandstats 中 cmdstat_decr 的 p99 延迟，超过 5ms 就得缩容
• 观察 MySQL 的 SHOW STATUS LIKE 'Threads_running'，持续 > 200 说明 DB 已开始排队
• CPU 长期 > 70% 或内存使用率逼近 90%，不是加机器，而是 channel 已超载，再撑下去会触发 OOM killer
• 如果用了 Gin，限流逻辑必须放在中间件里统一处理，而不是每个 handler 自己写一套 和 defer func(){

异步落单不是优化，是防止 503 的底线

秒杀成功的那一刻，只要 redis.Decr 返回 ≥ 0、订单号生成完成，就必须立刻 HTTP 响应。后面所有操作——写 MySQL、发 MQ、更新销量统计——全扔进异步队列。

• goroutine 卡住不归还 chan 令牌，新请求直接 503；sync.WaitGroup 只管收尾，不释放令牌，起不到限流作用
• 异步任务失败必须有重试 + 死信兜底，但重试不能拖慢用户侧响应；这是两层逻辑，不能混在一起
• Redis 库存 key 命名建议用 seckill:stock:{goodsID}，别用 sku:{goodsID}:stock —— 后者在集群 slot 分配或 keys 扫描时容易出错
• 真正难的不是写对一行 Decr，而是让 channel 容量、Redis 过期时间、SETNX 过期时间、异步队列重试策略这四组参数，在压测中形成闭环咬合

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。