秒杀接口压测超时主因是未用原子操作，如将GET/SET拆开导致超卖；应优先用DECR扣减并校验返回值，Go中redis.Client虽并发安全但需避免手动复用Cmdable或共用Conn，连接池与超时参数须按压测调优。
秒杀接口为什么一压就超时？Redis原子性没用对
Go写秒杀最常踩的坑，不是并发量扛不住，而是把 GET 和 SET 拆开用了——比如先查库存再减库存，中间插进来的请求全会读到“旧余量”，导致超卖。必须用原子操作兜底。
实操建议：
- 库存扣减优先用
DECR，它天然原子；返回值小于 0 就说明库存已耗尽，立刻return - 别用
INCRBY做“加库存”替代方案，秒杀场景下库存只减不增，DECR语义更清晰、出错路径更短 - 如果要用 Lua 脚本兜底（比如需要校验用户是否已抢过），脚本里必须用
redis.call("DECR", KEYS[1])，不能用redis.pcall包裹，否则原子性失效
Go 的 redis.Client 并发安全吗？别默认相信文档
官方 github.com/go-redis/redis/v9 的 redis.Client 是并发安全的，但前提是：你没手动复用 redis.Cmdable 实例，也没在多个 goroutine 里共用同一个 *redis.Conn（v9 已不暴露 Conn）。
容易出问题的点：
立即学习“go语言免费学习笔记（深入）”；
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 自己封装一个全局
redis.Cmdable变量并到处传参，看似方便，实则可能被误改内部状态 - 用
client.PoolStats()查连接池满载但无报错，其实是因超时设置不合理（如ReadTimeout: 100 * time.Millisecond），小延迟就卡死连接 - v9 默认启用
MinIdleConns，但若秒杀突发流量远高于预设值，新连接建立耗时会拖慢整体响应——建议显式设MinIdleConns: 50（根据压测调整）
库存预热和超卖兜底怎么配？别只靠 Redis TTL
单纯靠 SETEX goods:123 600 100 设置 10 分钟过期，解决不了“缓存击穿+瞬间并发”问题——万一 Redis 主从同步延迟，或刚好过期时刻大量请求涌入，照样超卖。
真实可用的组合策略：
- 预热时用
SET goods:123 "100" NX EX 600，NX防止覆盖已有库存键 - 扣减失败后，立刻用
GET goods:123+if val == ""判断是否击穿，是则触发本地限流（如golang.org/x/time/rate.Limiter）并异步重载库存 - MySQL 最终一致性校验放在下单成功后的异步任务里，而不是同步阻塞主流程；校验失败则发 MQ 回滚消息，不要直接删 Redis 键
Go 中如何避免 context 超时污染整个链路？
秒杀接口里常见错误：所有 Redis 操作都套同一份 ctx, cancel := context.WithTimeout(context.Background(), 200*time.Millisecond)，结果 DB 查询慢了 10ms，Redis 请求全被 cancel，反而放大雪崩。
合理拆分方式：
- Redis 扣库存用独立短超时：
redisCtx, _ := context.WithTimeout(ctx, 50*time.Millisecond) - 后续 DB 写入、MQ 发送用原始
ctx（带 API 层统一 timeout） - 千万别在 defer 里调
cancel()——goroutine 泄漏风险高；改用context.WithDeadline或明确作用域控制
Redis 不是银弹，Go 的 goroutine 也不是万能线程。真正卡点永远在“哪一步该放弃”和“放弃后怎么兜住”，而不是堆参数或换组件。
