Go语言秒杀系统实战详解

本文深入剖析了Go语言构建高并发秒杀系统的核心实践，直击限流、库存扣减、防超卖和缓存防护四大痛点：强调限流必须前置到网关层，用rate.Limiter按IP+User-Agent粗粒度拦截90%无效流量；库存扣减依赖Redis+Lua原子脚本并返回明确状态码，后续严格绑定MySQL订单插入（靠联合唯一索引防重单）；彻底规避超卖需确保MySQL使用唯一索引配合SELECT ... FOR UPDATE，拒绝非安全的count判断；针对缓存击穿，采用逻辑过期+singleflight+主动预热三重防御。全文没有空谈理论，而是以真实踩坑为线索，揭示Redis、MySQL与HTTP各层失败场景如何对齐，堪称Go工程师落地高可用秒杀系统的实战避坑指南。

秒杀请求压根没到业务层，先被限流吃掉了

Go 做秒杀，第一反应不是写 HandleFunc，而是看流量有没有资格进来。真实场景里，90% 的并发请求在到达 http.Handler 前就得被拦住——不然光是 goroutine 创建和上下文切换就把内存和调度器拖垮了。

实操建议：

• 用 golang.org/x/time/rate.Limiter 做网关级限流，每秒只放行 100 个请求（根据 Redis 集群吞吐反推），别用全局计数器或锁，那是性能黑洞
• 限流要放在 net/http.ServeMux 之前，比如用中间件包装 http.Handler，而不是在 handler 里判断
• 别依赖前端传来的 user_id 或 token 做限流依据——这些能伪造；按 IP + User-Agent 组合做粗粒度压制更实际
• 限流响应统一返回 HTTP 429 Too Many Requests，带 Retry-After 头，别返回 HTML 或重定向

库存扣减卡在 Redis + Lua，但没处理原子性失败

用 redis.Eval 扣库存看似原子，但常见错误是：Lua 脚本里只判断 stock > 0 就 decr，却没把「扣成功」和「下单记录写入」绑定成一个事务语义。结果 Redis 扣了，MySQL 没写，订单状态就永远卡在“待支付”。

实操建议：

• Lua 脚本必须返回明确结果，比如 1 表示扣成功、0 表示库存不足、-1 表示已抢完（避免重复执行）
• Go 侧拿到 1 后，立刻用 INSERT ... ON DUPLICATE KEY UPDATE 写订单表，主键设为 user_id + sku_id 防重单
• Redis 库存 key 命名用 stock:sku_123，别用 sku:123:stock——后者在 keys 扫描或集群 slot 分配时容易出错
• 别在 Lua 里做耗时操作（比如调用 TIME 或拼接字符串），脚本执行超时会直接被 Redis 中断，返回 nil

超卖还是发生了，问题出在 MySQL 的隔离级别和唯一索引

很多人以为加了 Redis 限流+Lua 扣减就万事大吉，结果上线后发现仍有超卖。根本原因：MySQL 默认 REPEATABLE READ 下，SELECT ... FOR UPDATE 在非唯一索引上可能锁住间隙（gap lock），导致并发更新行为不可预测；而唯一索引缺失又会让重复插入绕过约束。

实操建议：

• 订单表必须有联合唯一索引：UNIQUE KEY `uk_user_sku` (`user_id`, `sku_id`)，这是防重单的最后防线
• 扣减库存的 SQL 必须走唯一索引字段，否则 SELECT ... FOR UPDATE 可能升级为表锁，QPS 直接归零
• 不要用 UPDATE stock SET count = count - 1 WHERE sku_id = ? AND count > 0 —— 这个条件在并发下不保险，count 可能被多个事务同时读为 1，然后都减成 0
• 如果业务允许，用乐观锁：查出当前 version，更新时带上 WHERE version = ?，失败则重试（最多 2 次），比悲观锁吞吐高得多

秒杀结束后，缓存击穿让 DB 瞬间被打满

活动结束那一刻，大量用户刷订单页、查结果，Redis 里 order_result:user_789:sku_123 这类 key 过期，所有请求穿透到 MySQL。这不是缓存设计问题，是缓存生命周期没和业务状态对齐。

实操建议：

• 秒杀结果缓存不设固定 TTL，改用逻辑过期：value 里存 {"status":"success","expire_at":1717027200}，应用层检查时间再决定是否回源
• 所有查询接口加 singleflight.Group，相同 key 的并发请求只放行一个去查 DB，其余等待结果，避免雪崩
• 活动结束前 5 分钟，主动用 redis.Pipeline 预热一批热门 sku_id 的最终状态（如“已售罄”），key 设置永不过期
• 别用 GETSET 或 SETNX 做缓存加载互斥——它们没有超时自动释放机制，一旦 worker panic，锁就永远卡死

真正难的不是写对一个 redis.Eval，而是让 Redis、MySQL、HTTP 层的失败模式彼此对齐。比如 Lua 返回失败，HTTP 层得立刻终止；MySQL 插入失败，Redis 库存得回滚——这些边界 case 不写进测试，上线必出事。

理论要掌握，实操不能落！以上关于《Go语言秒杀系统实战详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！