分布式锁 Redisson

大学生学习记录，干货不多，佬请滑走。

redis 中手写 SETNX vs Redisson

1. 锁续期（看门狗机制），最大区别

手写 SETNX，必须手动固定锁超时时间

• 如果异步任务执行超过10秒，锁会自动过期释放。
• 其他线程抢到锁，再次提交任务 并发问题重现
• 超时时间设太长，线程崩溃会导致锁无法释放（死锁）。

Redisson 自带看门狗 自动续期机制：

• 默认锁超时30 秒
• 只要线程没执行完任务，后台线程每隔 10 秒自动给锁续期 30 秒

2. 可重入性

手写 SETNX 不支持重入，同一线程不能重复获取锁 Redisson 支持，同一线程可以多次加锁、多次释放，框架自动计数，绝对安全。

3.原子性

手写SETNX，加锁和释放锁是分开的redis命令，如果中间出现异常，可能导致锁无法释放 Redisson 所有操作都使用 Lua脚本 保证原子性

4. 主从一致性

SETNX

Redis 主从同步有延迟：主节点加锁成功 → 还没同步到从节点 → 主节点挂了 → 从节点变主 → 其他线程可以重新加锁（锁失效）。

Redisson

提供 红锁（RedLock） 解决主从延迟问题，生产高可用场景必备。

红锁

解决问题：redis主从架构下锁丢失的致命问题

普通主从 Redis 锁的 "死亡陷阱"

1. 客户端 A 在 Master 节点加锁成功
2. Master 宕机，此时锁数据还没来得及异步同步到 Slave
3. Slave 被提升为新 Master
4. 客户端 B 向新 Master 请求同一把锁，竟然也成功了
5. 结果：两个客户端同时持有同一把锁，互斥性被彻底破坏，可能导致数据错乱、超卖等严重问题

解决方案 多数派共识机制

核心思想：不依赖单个redis实例，而是与多个独立的redis节点交互，只有获得“大多数”节点的锁才算成功。 红锁的核心原理

1. 部署至少 5 个独立的 Redis 主节点（无主从关系，完全独立运行）
2. 客户端按顺序向所有节点发送加锁请求（使用相同 key 和随机值）
3. 统计成功获得锁的节点数，只有当数量≥N/2+1（多数派）时才认为加锁成功
4. 验证总耗时必须小于锁的过期时间，防止时钟漂移导致的问题
5. 解锁时必须向所有节点发送解锁请求