Redis+Lua防击穿的本质是利用Redis单线程原子执行特性，将库存检查、扣减、用户标记等操作封装为不可分割的脚本，彻底消除并发竞态；而穿透防护（如布隆过滤器）仅拦截无效key，无法解决热点key存在但并发修改导致的数据不一致问题。
为什么Redis+Lua能防击穿，而不是只靠缓存穿透防护？
击穿在秒杀里不是指缓存没命中（那是穿透），而是热点商品的库存校验和扣减被并发请求撕开时间窗口，导致查到“还有100件”，结果1000个请求同时扣减，库存变负。Lua脚本把GET、DECR、EXISTS、甚至HSET用户标记等操作打包进一个原子执行单元，Redis单线程串行跑完整个脚本，中间不被打断——这才是防击穿的本质。
库存扣减+用户去重必须写在一个Lua脚本里
常见错误是分开调用：先用INCRBY扣库存，再用HEXISTS查用户是否抢过。这两个命令之间存在竞态，两个请求可能都看到库存>0、也都还没写入用户记录，结果双双通过。
- 正确做法是把库存检查、扣减、用户标记三步全塞进一个Lua脚本，用
redis.call("GET", KEYS[1])读库存，redis.call("DECR", KEYS[1])扣减，再用redis.call("HSET", KEYS[2], ARGV[1], "1")写用户ID - 脚本开头加判断：
if tonumber(stock) ，避免扣成负数 - 返回值统一设计为数字：0表示已抢完，1表示成功，-1表示超时或异常，方便上层快速分支
脚本里不能用KEYS[1]直接当锁名，要拼接业务标识
比如优惠券秒杀，KEYS应该传"seckill:stock:1001"和"seckill:user:1001"两个键，而不是只传"1001"。否则不同优惠券共用同一个Lua执行上下文，会互相干扰。
- KEYS数组长度固定为2：第一个是库存key，第二个是用户去重hash key
- ARGV数组传用户ID（如
"user_12345"）和初始库存阈值（可选，用于兜底校验） - 别在脚本里调用
redis.call("TIME")或redis.call("RANDOMKEY")，这些命令在集群模式下不支持
执行失败时，别急着重试，先看返回值含义
脚本返回-1不等于失败，可能是库存刚好扣完；返回nil才是真异常（比如Redis连接中断）。很多团队在这里埋了坑：一看到非1就疯狂重试，反而加剧集群压力。
- 只对明确的网络错误（如
org.springframework.dao.RedisConnectionFailureException）做有限重试 - 对业务返回值（0、-1）直接走降级逻辑：返回“已售罄”或“您已参与过”
- 监控重点不是QPS，而是Lua脚本平均耗时和
redis.call()失败率，超过2ms就要警惕慢脚本
redis.call()从Redis取值完成——这意味着你不能在脚本里“先查活动时间，再决定是否放行”，必须把活动时间也存成key，用GET读进来判断。这个约束会让脚本变长，但换来的是真正的原子性。 
