简介高并发场景下库存扣减的原子性保障是系统稳定性的核心。传统数据库方案受行锁竞争与连接池瓶颈限制难以应对秒杀、限量购等瞬时流量。Redis基于单线程模型执行Lua脚本可将检查库存、扣减库存、标记用户等操作合并为原子步骤配合Gin框架提供高性能HTTP入口并借助限流与异步消息队列削峰填谷。这种“缓存脚本异步”的组合既能防止超卖又能有效支撑高并发请求。本文以Golang为语言结合Redis与Lua脚本从原子性原理、接口设计到压测验证完整解析秒杀系统的工程落地路径为后端开发者提供一套可直接复用的高并发解决方案。1. 秒杀系统一上线就崩先搞清高并发究竟崩在哪做秒杀最典型的翻车现场是开售 1 万件商品30 万请求在几秒内涌进来第一版接口直接对数据库执行update stock set count count - 1 where id ? and count 0。压测到 800 并发时库存变成负数用户疯狂下单成功客服被打爆。为什么这么简单的扣减语句会出问题因为在高并发下查库存和扣库存两个操作之间存在时间窗口并发请求同时读到了同一个剩余库存各自扣减最终超卖。标题里这套「Golang Redis Lua Gin」的组合就是针对这个问题最经典的工程解法Redis 扛住热点读Lua 脚本保证库存扣减原子性Gin 负责把 HTTP 请求串起来。这篇笔记写给正在写秒杀、抽奖、限量购的后端开发目标是让你看完能自己复现一个不超卖、能限流、可压测的秒杀接口。2. 库存扣减的原子性用 RedisLua 把超卖按死在源头2.1 为什么数据库扣减和分布式锁不是最优解先说数据库方案。UPDATE seckill_goods SET stock stock - 1 WHERE stock 0这句 SQL 本身不会超卖因为 InnoDB 在行锁粒度上保证了一次更新是原子的。但秒杀场景的瓶颈不在正确性而在吞吐所有并发请求都盯着同一行记录行锁竞争导致请求排队数据库连接被占满CPU 还没到瓶颈连接池先打满了。更麻烦的是如果业务里还要「先查库存再插入订单」这种多步操作事务长时间持有行锁死锁和锁等待会把数据库彻底拖垮。那用 Redis 分布式锁行不行常见做法是SET lock_key user_id NX EX 5这种方式给某个商品加锁拿到锁的业务方再去做库存扣减。这里有两个隐患第一锁的过期时间和业务执行时间很难匹配业务跑得慢锁先过期了另一个线程拿到锁进来两个请求同时扣库存第二Redis 主从切换时锁可能丢失需要引入 RedLock 这类方案复杂度上去了吞吐还降下来了。所以我的判断是分布式锁适合控制小规模互斥不适合秒杀这种瞬间高并发的热点扣减场景。真正干净的做法是利用 Redis 单线程执行模型把「检查库存、扣减库存、标记用户」这三步写成一个 Lua 脚本一次提交给 RedisRedis 在脚本执行期间不会穿插执行任何其他命令天然原子。脚本内部自己完成业务判断不需要外部加锁也不存在锁过期的问题。2.2 核心 Lua 脚本从检查库存到标记用户一步完成先设计 key 的命名。每个秒杀活动需要两个 key一个是库存 keyseckill:stock:{activityId}存的是剩余数量一个是用户已购 keyseckill:ordered:{activityId}用于标记已经抢到的用户 ID保证同一个用户不能重复下单。用户已购 key 用 Set 和直接 SET 都可以如果只做标记直接 SET 更省内存。-- 秒杀库存扣减脚本 -- KEYS[1] 库存key例如 seckill:stock:1001 -- KEYS[2] 用户已购key例如 seckill:ordered:1001 -- ARGV[1] 用户ID -- ARGV[2] 每人限购数量默认 1 -- ARGV[3] 活动剩余有效时间秒用于给用户已购标记设置 TTL0 表示活动结束后统一清理 -- 第一步检查用户是否已经抢过 if redis.call(exists, KEYS[2]) 1 then return -1 -- 已参与返回业务码 -1 end local stock tonumber(redis.call(get, KEYS[1]) or 0) local limit tonumber(ARGV[2]) -- 第二步剩余库存是否足够 if stock limit then return -2 -- 库存不足返回业务码 -2 end -- 第三步扣减库存 redis.call(decrby, KEYS[1], limit) -- 第四步标记用户已购买 redis.call(set, KEYS[2], 1, EX, ARGV[3]) return 1 -- 抢购成功这段脚本有几个地方需要重点说明。redis.call(exists, KEYS[2]) 1这种判断提前挡住了重复请求这里必须用 exists 而不是 get因为 set 的值可能是 1也可能是任意字符串exists 更能表达「这个 key 是否存在」的语义。库存检查放在用户去重之后是为了让已经抢过的用户直接返回不参与后续的库存判断减少无意义的读操作。扣减使用decrby它本身是原子命令但在 Lua 脚本里它的价值在于和前面的检查组合成一个不可分割的整体而不是单独使用。返回值语义也很关键。这里约定1成功、-1重复下单、-2库存不足Go 侧拿到结果后不需要再查任何状态直接根据返回码给出用户响应。要注意 Lua 脚本里return -1时go-redis 拿到的结果类型是int64如果你的代码里用了redis.Nil来判断错误在这里是完全不适用的因为脚本正常执行完不会返回 Redis 错误只是返回一个负数业务码。2.3 Go 侧调用脚本连接池参数和返回值处理调用 Lua 脚本不必把脚本内容存到 Redis 端go-redis 的Eval方法执行时会把脚本和参数一起发给 RedisRedis 内部会对脚本做 SHA 缓存。下面是用 go-redis v8 的完整调用代码连接参数是重点直接关系到压测能不能扛得住。package main import ( context time github.com/gin-gonic/gin github.com/go-redis/redis/v8 ) var rdb *redis.Client func initRedis() { rdb redis.NewClient(redis.Options{ Addr: 127.0.0.1:6379, Password: , DB: 0, PoolSize: 200, // 连接池最大连接数 MinIdleConns: 50, // 预热空闲连接避免流量洪峰时新建连接 DialTimeout: 3 * time.Second, // 建立连接超时 ReadTimeout: 5 * time.Second, // 读超时防止 Redis 阻塞导致 goroutine 堆叠 WriteTimeout: 5 * time.Second, // 写超时 }) } const stockLuaScript -- 上一节完整脚本粘贴到这里 func seckillHandler(c *gin.Context) { userId : c.GetString(userId) activityId : c.Param(id) result, err : rdb.Eval(context.Background(), stockLuaScript, []string{ seckill:stock: activityId, seckill:ordered: activityId, }, userId, 1, 3600).Result() if err ! nil { // 这里要区分两种错误脚本执行报错和 Redis 网络错误 c.JSON(500, gin.H{code: 500, msg: 系统繁忙}) return } code : result.(int64) switch code { case 1: // 抢购成功接下来把订单信息丢进异步队列 c.JSON(200, gin.H{code: 0, msg: 抢购成功}) case -1: c.JSON(200, gin.H{code: -1, msg: 您已经参与过该活动}) case -2: c.JSON(200, gin.H{code: -2, msg: 库存不足}) } }参数说明里最值得关注的是PoolSize和MinIdleConns。秒杀流量是脉冲式的如果连接池只有 50 个连接第一波请求到达时 Redis 连接会被打满后续请求全阻塞在取连接上。我一般会把 MinIdleConns 调大让连接提前建立好PoolSize 根据压测结果逐步往上加但不要无脑加到 500 以上因为 Redis 是单线程的连接数再多也只是在排队。另一个点是ReadTimeout默认 3 秒在低并发下没问题秒杀时如果 Redis 里跑了大 key 的慢命令读超时会让大量 goroutine 同时报错形成雪崩建议单独排查慢日志。result.(int64)这个类型断言要写个防御逻辑因为Eval返回的interface{}在 Redis 返回小整数时通常解析为int64但如果脚本里某个分支return redis.status_reply(...)类型就变成了 string。我习惯的做法是让脚本只在最后返回整数错误路径全部用负数表达正好对应业务码。3. 用 Gin 串起秒杀接口路由、参数校验与初始化细节3.1 项目初始化与依赖选择标题里指定了 Gin但先回答一个常见问题Go 的 Web 框架里 go-zero、beego、Gin 选哪个秒杀接口本身很薄核心逻辑几乎全在 Redis 和 Lua 里框架层只需要提供路由注册、中间件、参数绑定这三件事。Gin 的httprouter性能在纯路由分发上不输任何框架生态大资料多出了问题容易搜到答案。go-zero 适合你还需要微服务拆分、熔断降级、链路追踪这些重型能力的场景但秒杀项目单机就能扛很大一部分流量重框架反而增加了理解成本。beego 则更偏全栈 Web 框架自带 ORM 和 session放在高并发入口处没有明显收益。mkdir seckill-demo cd seckill-demo go mod init seckill-demo go get github.com/gin-gonic/ginlatest go get github.com/go-redis/redis/v8latest初始化之后目录结构我一般分成三层。main.go只做启动和依赖装配handler目录放 HTTP 层的路由和中间件service目录放 Redis 调用和 Lua 脚本。秒杀系统不建议把业务逻辑写成一个大包因为后面你要加限流、加异步订单、加活动配置管理不分层会非常痛苦。但也不要照搬含 domain、repository、application 的大企业分层秒杀这种场景下过度抽象会让后来维护的人绕来绕去。3.2 路由注册与统一响应中间件Gin 的路由要单独拿出来说。秒杀接口对外只需要一个POST /api/v1/seckill/:id其中id是活动编号。为什么用 POST 而不是 GET因为这是一个写操作GET 会被浏览器预加载、被 CDN 缓存甚至被爬虫扫描而且 GET 的参数会出现在访问日志里活动 ID 和用户 ID 都暴露出去会增加刷接口的风险。路由注册和用户身份校验中间件写在一起func main() { gin.SetMode(gin.ReleaseMode) // 关闭 Gin 的调试日志压测时减少无谓的 IO r : gin.New() r.Use(gin.Recovery()) // 恢复 panic不让单个请求崩溃整个进程 api : r.Group(/api/v1) api.Use(UserAuthMiddleware()) { api.POST(/seckill/:id, seckillHandler) } srv : http.Server{ Addr: :8080, Handler: r, ReadTimeout: 5 * time.Second, // 防止客户端慢速连接占用 goroutine WriteTimeout: 5 * time.Second, } srv.ListenAndServe() }UserAuthMiddleware是凭据解析的地方。秒杀接口不能依赖用户的 Cookie因为高并发下 Cookie 解析本身有开销而且移动端 App 未必带 Cookie。常见做法是让客户端在 Header 里传X-User-Id和X-Token中间件里校验签名后把用户 ID 写入 context。注意中间件里不要查数据库任何一次数据库查询都会放大几十万倍压力用户信息用 Redis 缓存或者直接在签名里带上用户 ID 做对称加密校验省掉一次网络往返。参数绑定上c.Param(id)拿到的活动 ID 必须做一次存在性检查不能直接拼进 Redis key。如果用户传一个不存在的活动 IDseckill:stock:999999返回空Lua 脚本会把库存当 0 处理返回库存不足这没问题。但为了给运营人员清晰的错误提示我会在进入秒杀逻辑前查一下活动配置表这个表也要缓存在 Redis 里不能用数据库实时查询。3.3 秒杀响应的语义不要用 HTTP 状态码表达业务结果一个经常被新手忽略的点秒杀接口的 HTTP 状态码永远返回 200业务成功与否用响应体里的code字段表达。为什么因为秒杀接口前面往往会挂网关或负载均衡如果大量返回 4xx/5xx网关会触发熔断或告警把正常的业务失败也当成系统故障。用户抢不到库存、重复下单这是业务状态不是 HTTP 错误。func seckillHandler(c *gin.Context) { userId : c.GetString(userId) activityId : c.Param(id) // 标准做法先用 Lua 脚本原子扣库存扣成功才异步落单 result, err : rdb.Eval(context.Background(), stockLuaScript, []string{ seckill:stock: activityId, seckill:ordered: activityId, }, userId, 1, 3600).Result() if err ! nil { c.JSON(200, gin.H{code: 500, msg: 系统繁忙请重试}) return } code : result.(int64) switch code { case 1: // 扣库存成功订单交给异步队列处理 // 这里不要立即写数据库否则又回到了数据库扛压的老路 orderCh - OrderTask{UserId: userId, ActivityId: activityId} c.JSON(200, gin.H{code: 0, msg: 抢购成功}) case -1: c.JSON(200, gin.H{code: -1, msg: 您已经参与过该活动}) case -2: c.JSON(200, gin.H{code: -2, msg: 库存不足}) default: c.JSON(200, gin.H{code: 500, msg: 系统繁忙请重试}) } }这里把订单丢进orderCh是做异步解耦的一个常见做法后面第 4 章会展开。异步落单的好处是请求线程只花了几毫秒就返回给用户真正的订单写入放在后台慢慢消化。但要注意orderCh是一个内存 channel进程重启消息就丢了适合单机 demo 和压测验证生产环境要换成 Kafka 或 RabbitMQ 这类持久化消息队列。我在给团队做代码评审时经常见到这个坑demo 代码直接抄到生产环境一重启秒杀订单丢了一半这是必须要强调的边界。4. 削峰填谷限流、用户去重与异步落单的落地方案4.1 全局限流用 Redis 计数器挡住绝大多数流量库存扣减做好之后另一个核心问题是流量防护。1 万件库存30 万请求即使 Redis 能扛住也不应该让 30 万请求全部打到库存扣减脚本上。合理的做法是在秒杀链路最前面做限流只放行大约库存量 5 到 10 倍的请求进入后面的逻辑剩下的直接返回「活动太火爆」。限流算法在秒杀场景下我最常用的是固定窗口加滑动窗口的折中方案。固定窗口实现简单但有个临界问题窗口切换的一瞬间可能涌进两倍流量。滑动窗口需要记录每个请求的时间戳内存占用高。秒杀库存有限固定窗口即使临界流量翻倍也翻不出库存量级的风险所以我一般先用固定窗口配合 Redis 的INCR和EXPIRE-- 固定窗口限流脚本 -- KEYS[1] 限流计数器 key例如 rate:limit:seckill:1001 -- ARGV[1] 窗口内最大请求数 -- ARGV[2] 窗口大小秒 local count redis.call(incr, KEYS[1]) if count 1 then -- key 之前不存在说明是新窗口设置过期时间 redis.call(expire, KEYS[1], ARGV[2]) end if count tonumber(ARGV[1]) then return 0 -- 被限流 end return 1 -- 放行这段脚本的核心逻辑是第一个请求进来时INCR返回 1说明这是新窗口的第一次请求给 key 设置过期时间后续请求累加计数超过上限就返回 0。为什么用 Lua 脚本而不是在 Go 里先INCR再判断因为INCR和EXPIRE虽然是两个命令但在 Lua 脚本里执行时是原子性的不会出现 key 已过期但计数器残留的问题。限流中间件在 Redis 返回 0 时直接返回「系统繁忙」不再执行后面的业务逻辑。窗口大小和请求上限这两个参数需要根据活动预期流量调整。我一般这样算预计峰值 10 万 QPS库存 1 万放行倍率设为 5 倍即窗口内最多放行 5 万个请求窗口大小为 1 秒。这样意味着每秒只有 5 万个请求能进入 Redis 库存扣减层剩下的 5 万直接挡掉。PoolSize和这个值匹配起来也更简单因为实际的 Redis 并发量是可控的。4.2 用户维度去重布隆过滤器与 Lua 脚本的取舍用户去重是防刷的关键一环。想象一个黄牛用脚本同时发 10 个请求如果不去重这 10 个请求可能扣掉 10 件库存。第 2 章 Lua 脚本里已经通过seckill:ordered:{activityId}这个 key 做了同一用户的重复拦截但这里有个成本问题每个用户请求都要先EXISTS一次这个 keykey 的数量和抢购成功的人数成正比。如果秒杀活动的参与人数高达几百万而库存只有几千只在抢购成功时才标记用户问题是未抢到的人会反复请求每次都走到库存判断。这时候可以在请求入口加一道布隆过滤器用活动 ID 加用户 ID 做哈希空间占用是 bitmap比存储几百万个 Redis key 省得多。不过布隆过滤器有误判会把「没抢过的用户」误判为「抢过的用户」导致用户明明第一次参与却说已参与。这个误判率一般设置在 0.1% 左右需要 10 到 20 个比特位几百万用户也就几十兆内存是可接受的。我一般不会一上来就加布隆过滤器而是先压测看 Redis 内存和响应时间。如果单个活动参与用户在 10 万以内直接使用 Lua 脚本里的 user key 去重就够了省掉一层维护。只有当参与人数达到百万级别或者单个 Redis 实例内存告急时才引入布隆过滤器而且要接受那一小部分被误判的用户投诉。4.3 异步落单把数据库写入和扣库存彻底解耦秒杀链路里最容易拖垮系统的是数据库下单操作。用户抢到库存后要插入订单表、扣减商品表、更新用户积分这些操作如果全部同步执行一个请求的响应时间可能从 5 毫秒膨胀到 200 毫秒数据库连接随之被打爆。库存扣减和订单创建在业务上本就不是强一致的关系——只要保证「库存扣了订单最终能创建出来」就行这中间的延迟用户感知不到。// 全局订单缓冲 channel缓冲长度为库存量的 2 倍 var orderCh make(chan OrderTask, 20000) func initOrderConsumer() { // 启动固定数量的 worker 消费订单 for i : 0; i 20; i { go func() { for task : range orderCh { createOrder(task.UserId, task.ActivityId) } }() } } type OrderTask struct { UserId string ActivityId string }channel 在这里扮演了一个内存队列的角色秒杀请求处理完库存扣减后把订单任务写入 channel 立即返回。后台有 20 个 goroutine 从 channel 里取任务调用createOrder写数据库。这个设计有三个关键参数。第一个是 channel 缓冲长度。设为库存量的 2 倍是因为秒杀瞬间可能比库存量多出一倍的实际成功请求比如用户取消订单后库存回滚但回滚前的标记 key 仍存在缓冲设太小 channel 会写满阻塞前面的秒杀请求设太大内存占用高。第二个是 worker 数量。20 个 goroutine 对于单机 MySQL 来说已经是比较高的写入并发worker 太少订单积压用户抢到订单迟迟不生成太多数据库报连接错误。第三个是失败处理。createOrder里如果数据库写入失败最简单的兜底是打日志后重试三次再失败就丢进一个死信表后续人工处理。绝不能在 worker 里 panic否则整个消费者协程退出后续订单全部积压。生产环境我更推荐直接用 MQ比如 RabbitMQ 或者 RocketMQ。为什么因为 channel 在进程重启会丢消息秒杀刚开售你重启一次服务缓冲队列里的几千个订单就没了。但 demo 和内部压测用 channel 没有问题它让你无额外依赖地理解「削峰填谷」的核心思想把同步模型改成异步模型让流量在队列里排队系统背压不外溢。5. 避坑指南秒杀系统最容易踩的 6 个现场5.1 现象压测刚开始 Redis 连接就超时大量请求报context deadline exceeded先说现象背后的原因。这类超时绝大多数不是 Redis 真的挂了而是连接池被耗尽后又叠加了慢命令。比如排查时发现在 Lua 脚本里无意识地调用了KEYS命令——这是 Redis 里最典型的慢命令它会遍历整个 keyspace单线程的 Redis 会被卡住几十毫秒甚至几百毫秒期间所有其他命令排队连接读超时雪崩。解决方法是先查慢日志SLOWLOG GET 20看有没有耗时长的大 key 操作。然后调整 go-redis 的PoolSize和MinIdleConns但不要只调大连接池因为 Redis 单线程情况下连接多了也是排队。还有个隐藏点检查是否有请求在持有连接时做了BLPOP这类阻塞命令秒杀场景下绝不能用。最后把ReadTimeout从默认的 3 秒适当调到 5 秒给慢命令一些额外余量但要记住这只是缓冲不是根治手段。5.2 现象库存明明用了 Lua 脚本压测后数据库显示超卖这是最诡异的一个场景第一反应都是怀疑 Lua 脚本有问题。我排查过类似项目最后发现脚本本身没问题问题出在库存预热环节——运营人员把初始库存 10000 在活动开始前用SET写进了 Redis但库里压测前又被手动插入了一条订单导致 Redis 里剩余库存和数据库实际剩余对不上。另一种常见的超卖原因是回滚逻辑写的。用户下单后如果支付超时取消订单库存要回补回补路径上没有走 Lua 脚本而是直接INCR此时如果有人同时用 Lua 脚本扣库存INCR和DECRBY交叉执行数据库里的扣减记录就乱套了。解决方法是把库存回补也做成一个 Lua 脚本保证所有修改库存的操作走同一条原子路径不能一部分走脚本一部分走裸命令。5.3 现象Lua 脚本正常返回值但 Go 侧判断逻辑全乱了这个坑出在类型上。Redis 的 Lua 脚本里return 1和return true返回的数据类型不同go-redis 拿到的interface{}实际类型可能是int64也可能是string。如果脚本里有return redis.status_reply(OK)这类写法Go 侧result.(int64)会直接 panic。更隐秘的是tonumber(redis.call(get, KEYS[1]) or 0)里如果 key 不存在redis.call(get)返回false经过or 0处理后 Lua 会把 false 和字符串拼接成字符串再tonumber转换时行为可能不符合预期。解决方法是规范脚本输出。所有返回值统一用整数if判断里显式处理false和nil并且在 Go 侧解析时先switch v : result.(type)做类型分派再转int64。还有一点要在本地写好测试用redis-cli --eval手动执行脚本验证每个分支不要直接丢到高并发环境里试错。5.4 现象Gin 服务 CPU 不高但压测 QPS 上不去响应大量 5xxCPU 不高说明瓶颈不在业务代码算力而很可能在连接层和进程资源。先查系统的ulimit -n默认 1024 的文件描述符意味着最多几百个并发连接压测 QPS 当然上不去。把ulimit -n调到 65535 以上是第一步。再查 Gin 是否设成了 release 模式开发默认的 debug 模式会往控制台打印每一条请求日志高并发下写日志的 IO 开销非常大但 CPU 并不高因为瓶颈在磁盘 IO。还有http.Server的参数设置。如果没设置ReadTimeout慢速连接攻击能把连接占满没有WriteTimeout响应写不出去就一直挂起goroutine 越积越多。最后查一个很多人忽略的点有没有在 handler 里调用了c.Request.Body读取但不关闭导致连接无法复用。Gin 框架本身会处理 body 的回收但你自己读取 body 之后要defer c.Request.Body.Close()否则连接池很快耗尽。5.5 现象活动还没结束Redis 里的库存 key 和用户标记 key 神秘消失这个通常被归为「玄学」实际是 TTL 设置没有统一。库存 key 初始化时不建议设置EXPIRE因为库存应该由活动状态控制活动结束由后台脚本来删除或归档。但用户标记 key 如果你按照第 2 章的方式设置了EXPIRE过期时间一定要设为活动结束时刻减去当前时刻而不是一个固定的小数字。比如活动持续 1 小时你给用户标记 key 统一设置 3600 秒没问题但如果在活动最后 5 分钟才抢购key 在活动结束前 55 分钟就过期了用户可以再次下单造成超卖。解决方法是初始化活动时把过期时间算好写进活动配置脚本里用ARGV[3]接收的剩余有效时间是从当前时间到活动结束的差值保证 key 至少活到活动结束。如果活动延期需要在管理后台提供一个补 TTL 接口不能依赖原 key 的设置。这里还要注意 Redis 的过期删除策略是惰性删除加定时抽样过期 key 不会立刻消失如果你在活动结束后立刻统计订单可能把已过期但未删除的用户标记也统计进去业务上要把这个因素考虑进去。6. 压测验证与分布式扩展调参边界和下一步往哪走秒杀系统写完不能直接上线先用压测数据说话。我习惯用wrk做最粗粒度的验证它比ab更能模拟连接复用的真实场景。压测前先确认库存 key 已预热Redis 里seckill:stock:1001是实际库存值然后把 Gin 设为 release 模式再用下面的命令打流量wrk -t 8 -c 100 -d 30s -s seckill.lua http://127.0.0.1:8080/api/v1/seckill/1001压测脚本里每个请求带上不同的X-User-Id模拟真实用户。压测结束看两个指标一是请求成功率和 TP99 响应时间正常秒杀接口 TP99 应该在 20 毫秒以内二是核对 Redis 里的库存 key 不为负数seckill:stock:1001的值和数据库中订单实际落库数量加起来要等于初始库存这是验证有没有超卖的硬指标。如果你准备把单机方案扩展成分布式集群第一个遇到的墙就是 Redis Cluster 对 Lua 脚本的限制脚本里访问的所有 key 必须落在同一个 slot。解决办法是给 key 加 hash tag比如seckill:{1001}:stock和seckill:{1001}:ordered花括号里的内容会参与 hash 计算确保同一个活动 ID 的两个 key 落到同一个 slot。Gin 服务可以横向扩展但订单消费的 channel 是单机的扩展到多实例时必须把 channel 替换成真正的 MQ否则每个实例各消费各的订单状态无法全局统一。最后说一个我的习惯也当是给你的提醒秒杀系统的成败往往不在代码本身而在上线前的流量预估和压测覆盖。我带团队时见过太多方案逻辑完美但上线前没有做全链路压测活动一开始就发现 Redis 没预热、限流阈值不对、连接池太小最后被运营追着骂。给任何一个秒杀接口做改动都要先回到压测这条基准线上重新验证。这套方案到此是可以照着复现的参数都给到了具体值希望你跑通之后能压出满意的数据也希望能帮到你。本文还有配套的精品资源点击获取