分布式锁

结论先行 分布式锁/租约的"生死"记在 server 的钟上，"续命的节奏"却记在 client 的墙钟上。当 NTP 一次回拨把客户端本地时钟往回拽 12 秒，server 认为租约已过期把锁让给了别人，而旧持有者还以为自己持有——这个"

«结论先行："SET key val NX" 拿到锁这件事，本身不携带任何持久性保证。在 Redis Sentinel / 主从架构里，锁是写在单机主库上的一条普通 key，靠异步复制传给从库——主库在复制确认前宕机，这条锁就会从整个集群里

一、现象：1000 张券，被"领"了 2371 次 去年双 11 前的预热活动，我们上一张满 200 减 50 的优惠券，计划只发 1000 张。活动开抢后 3 分钟，客服后台就炸了：发券流水 2371 条，其中同一个 user_id 重复

【背景】 我负责一个库存扣减服务：JDK 17 + Spring Boot 3 + Redis 7（Cluster）+ Lua 脚本，核心链路是用 Redis 分布式锁保证「读库存→判断→扣减→回写」的原子性。锁是自己实现的 Redlock

一、现象：一次秒杀活动，100 件库存卖出了 137 件 上个月我们上一场限时秒杀，目标是把某个 SKU 的 100 件库存放出去。活动开始后的 90 秒内，订单系统实际落库了 137 单，多扣了 37 件——这在库存层面意味着超卖 37%