学完分布式锁和限流，如果没有实战，你只是“知道”。
跑过一遍 Demo，你才是“会用”。
本文目标：
用Spring Boot + Redis做一个最小实战，验证三件事：
- 没有锁会并发冲突
- 有锁但不校验 UUID 会误删
- 正确锁（UUID + 原子解锁）才安全
- 再加一层限流，形成“门禁系统”
一、实验场景设计
我们模拟一个经典业务：扣库存
特点：
- 并发高
- 容易超卖
- 非常适合验证锁
资源：
商品ID：sku=1001 初始库存：1二、实验环境
学习阶段一台电脑就够：
本机 Redis（或 Docker Redis）
两个 SpringBoot 实例
localhost:8080localhost:8081
这两个实例共用一个 Redis，
就等价于“两台服务器”。
三、第一步：没有锁的情况
接口逻辑（伪代码）：
if stock > 0: stock--并发请求时可能出现：
库存=1 A读取=1 B读取=1 A扣减=0 B扣减=0结果：超卖
四、第二步：加锁但错误解锁
加锁：
SET lock:sku:1001 uuid NX PX 30000解锁：
DEL lock:sku:1001风险场景：
- A 执行慢
- 锁过期
- B 拿锁
- A 执行完直接 DEL
- 把 B 的锁删了 ❌
五、第三步：正确分布式锁
加锁
SET lock:sku:1001 uuid NX PX 30000关键点：
- NX：不存在才设置
- PX：过期时间
- uuid：锁身份
解锁（Lua 原子）
逻辑：
如果当前 value == 我的 uuid 删除 否则 不删除意义：
- 防误删
- 防并发插队
六、加入限流 —— 门口再加一道闸
为什么要限流？
锁解决的是“同一资源冲突”，
限流解决的是“人太多把系统打爆”。
最简单限流思路
每秒最多 5 次请求：
key = limit:api:stock count++ 过期1秒 >5 拒绝七、最终完整流程
请求进来 ↓ 限流（挡住洪水） ↓ 分布式锁（保护资源） ↓ 业务执行 ↓ UUID 原子解锁这就是一个最小的并发门禁系统。
八、你通过实战能学到什么？
| 能力 | 价值 |
|---|---|
| Redis 锁机制 | 企业级并发思维 |
| UUID 解锁 | 防误删 |
| Lua 原子操作 | 工程严谨性 |
| 限流设计 | 系统保护意识 |
| 多实例模拟 | 分布式思维 |
九、面试一句话总结
分布式锁用 Redis SET NX PX 实现，加 UUID 防误删，解锁用 Lua 原子校验；
限流用计数器或令牌桶算法保护系统，两者结合形成并发门禁机制。
十、一句话收尾
锁解决“抢同一资源”，
限流解决“来太多人”。
两者结合，你才真正具备并发系统设计能力。
