Redis+Lua为何成为秒杀系统的黄金组合
秒杀场景下每秒数万次请求打到库存服务时，MySQL直接宕机的案例比比皆是。去年某头部电商618大促期间，单纯依靠数据库行锁导致整个交易链路雪崩，直接损失超3000万。而采用Redis+Lua的方案，某手机品牌新品首发实现了200万QPS下零超卖。
Redis的三大特性完美匹配秒杀需求：
但真正让这套方案落地的，是Lua脚本带来的四大突破：
秒杀系统的核心挑战与应对策略
当10万人同时点击秒杀按钮时，系统要同时解决三个致命问题：
| 问题类型 | 传统方案 | Redis+Lua方案 |
|---|---|---|
| 库存超卖 | 数据库乐观锁 | 原子化DECR+判断 |
| 热点Key | 应用层缓存 | Redis分片+本地缓存 |
| 流量控制 | Nginx限流 | 令牌桶+Lua脚本 |
Lua脚本的实战编写技巧
写一个可靠的秒杀脚本要考虑这些细节：
-KEYS[1] 商品库存key
-
ARGV[1] 购买数量
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock
return 0
end
if stock >= tonumber(ARGV[1]) then
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1
end
return 0
这个脚本实现了三个关键功能：
但实际生产环境还需要处理：
性能优化与异常处理
某电商平台实测数据显示，使用Lua脚本后：
但要注意这些坑：
当Redis集群出现故障时，要有降级方案：
当Lua脚本执行失败时，最怕的就是出现”半吊子”状态——库存扣了但订单没生成，或者反过来。这时候就得靠精心设计的补偿机制来擦屁股了。首先得让脚本明确返回成功、失败或者需要重试的状态码，客户端拿到失败码后别急着放弃，先查查本地操作日志，看看这笔交易到底走到哪一步了。比如有个电商平台的做法就挺聪明，他们在Redis里存了每笔交易的预扣减记录，同时本地数据库也记了流水账，两边数据每隔5-10秒就会自动对一次账。
对账的时候要是发现两边对不上，补偿程序就立马启动。比如说发现Redis里库存扣了但订单没生成，就会尝试重新创建订单；要是订单生成了但库存没扣，那就得回滚订单。这套机制最关键的是要给每个操作打上唯一标识，像订单ID、用户ID这些都得记全了，不然补都不知道往哪补。某生鲜平台上线这套系统后，把凌晨促销时段的异常订单从每分钟30多单直接压到了几乎为零，而且补偿过程完全自动化，运维半夜再也不用爬起来手动修数据了。
为什么Redis+Lua比数据库事务更适合秒杀场景？
Redis的内存操作比磁盘IO快100-1000倍，Lua脚本的原子性执行避免了网络往返开销。数据库事务在高并发下会产生锁竞争，而Redis单线程模型天然规避了这个问题，某实测案例显示QPS从5000提升到200万时仍保持稳定。
Lua脚本执行失败后如何保证数据一致性？
需要在脚本中设计状态返回值，客户端根据返回值决定重试或终止。典型做法是配合本地日志记录操作流水，设置5-10秒的异步核对任务，发现不一致时触发补偿机制，某电商平台采用此方案后异常订单率降至0.001%以下。
如何防止恶意用户刷单？
采用三层防护：前端按钮防重复点击，网关层IP限流1-3次/秒，Lua脚本内校验用户ID黑名单。某3C品牌秒杀活动通过该方案拦截了12万次机器人请求，正常用户购买成功率提升60%。
Redis集群故障时如何降级处理？
准备双活集群并设置5-10%的库存冗余，当主集群不可用时，秒级切换备用集群同时启用本地缓存。某大促期间主集群宕机17秒，因备用方案及时接管，用户完全无感知。
脚本中的库存扣减和订单创建如何保证原子性？
采用两阶段方案：Lua脚本只做预扣减，返回成功后通过消息队列异步创建订单。设置30-60秒的订单超时机制，未支付的库存自动回滚，该方案在某图书秒杀中实现零超卖且订单创建成功率99.99%。
