redis分布式锁不能只用set命令，因无法保证解锁安全；正确做法是用lua脚本原子校验并删除；redlock在多数场景不必要，单节点+哨兵/集群更实用；spring boot中需注意序列化、单位、续期等问题；幂等与补偿机制比锁本身更重要。
Redis 分布式锁为什么不能只用 SET key value EX seconds
因为这只能保证「加锁」原子性，但无法保证「解锁」安全——业务出错、超时、节点宕机时，可能删掉别人持有的锁。
真实场景里，锁的持有者必须严格校验：只有自己设的值，才能自己删。
常见错误是写个 DEL key 就完事，结果 A 拿着锁超时了，B 重新加锁，A 回来一删，把 B 的锁干掉了。
正确做法是用 Lua 脚本保证「判断+删除」原子执行：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end其中 KEYS[1] 是锁 key，ARGV[1] 是客户端唯一标识（比如 UUID 或服务实例 ID）。
Redlock 算法在微服务中真的必要吗
大多数业务场景下，不需要 Redlock。
它要求同时向 5 个独立 Redis 节点请求锁，多数成功才算拿到，用来对抗单点故障；但代价是延迟高、实现复杂、且实际故障模型并不匹配多数微服务部署方式。
更现实的选择是：
- 用单节点 Redis + 哨兵（Sentinel）或集群（Cluster），保障可用性
- 锁 key 设置合理过期时间（如 30 秒），避免死锁
- 业务侧配合重试 + 幂等设计，而不是依赖强一致性锁
Spring Boot 里用 RedisTemplate 实现锁要避开哪些坑
直接封装 setIfAbsent 很容易漏掉几个关键点：
- 没传
TimeUnit，导致过期时间单位错成毫秒或纳秒 - 用
StringRedisTemplate时，value 默认序列化成字节数组，Lua 脚本里GET出来的是乱码，比对永远失败 - 没处理锁续期（lease time），长任务中途锁过期，引发并发冲突
RedisTemplate<string string></string>，value 显式设为字符串；续期用单独线程 + GETSET 校验原值，或者直接换成熟轮子如 Redisson 的 RLock。
锁失效后业务怎么不崩——幂等和补偿才是重点
再严谨的分布式锁，也无法 100% 防住竞争。网络分区、GC 停顿、Redis 主从异步复制，都可能导致锁语义弱化。
所以真正可靠的方案不是“锁得更死”，而是让操作本身可重入、可抵消：
- 数据库写操作带唯一约束（如订单号唯一），冲突直接报错而非覆盖
- 更新前先查当前状态，用
UPDATE ... WHERE version = ?做乐观锁 - 发消息触发下游时，加本地事务表 + 定时扫描，确保最终一致
最容易被忽略的是：锁 key 的粒度。用用户 ID 锁住整个账户操作，不如用订单 ID 锁具体订单——粒度太粗会人为制造瓶颈，反而放大竞争。
