Redis 分布式锁、红锁分别是什么？红锁有什么问题？

Redis 分布式锁基础实现

基本实现方式（SETNX + 过期时间）

SET lock_key unique_value NX PX 30000

关键点：

1. 使用 NX 保证原子性获取锁
2. 设置合理的过期时间(PX)防止死锁
3. 释放锁时校验value防止误删(Lua脚本保证原子性)

存在的问题

1. 单点问题：主从切换可能导致锁失效
2. 过期时间难题：业务执行时间超过锁过期时间
3. 时钟漂移问题：不同节点时间不一致

Redlock（红锁）算法

红锁是Redis作者提出的分布式锁算法，用于解决单Redis实例的可靠性问题。

红锁实现步骤

1. 获取当前时间（毫秒）
2. 依次尝试从N个独立的Redis实例获取锁
3. 计算获取锁总耗时，当且仅当在多数节点(N/2+1)上获取成功且总耗时小于锁有效期时，认为获取成功
4. 锁的实际有效时间 = 初始有效时间 - 获取锁耗时
5. 如果获取失败，则向所有节点发起释放锁请求

红锁的问题与争议

1. 性能成本高

   • 需要部署多个独立Redis实例
   • 每次加锁/解锁需要与多个节点交互

2. 仍然存在的可靠性问题

   • 网络分区可能导致多个客户端同时持有锁
   • 节点崩溃重启可能导致锁状态丢失（即使开启持久化）

3. 时钟依赖问题

   • 依赖系统时钟的正确性
   • 时钟跳跃可能导致锁提前失效或超时计算不准确

4. 争议观点

   • Martin Kleppmann曾撰文指出红锁在特定故障场景下无法保证安全
   • Redis作者Antirez回应认为在合理假设下红锁是可行的

红锁的替代方案

1. Zookeeper/etcd实现

   • 基于临时顺序节点的更强一致性保证
   • 但性能通常低于Redis方案

2. 业务层解决方案

   • 使用fencing token机制
   • 结合数据库唯一约束

3. Redis企业版方案

   • Redis企业版提供的WAIT命令增强数据同步
   • 官方推荐的RLock对象

实际应用建议

1. 红锁适用场景

   • 需要高可靠性的非关键路径业务
   • 可以容忍偶尔的锁失效但要求低概率

2. 不适用场景

   • 对安全性要求极高的金融交易
   • 无法接受任何锁失效的情况

3. 最佳实践

   • 如果使用红锁，建议至少5个独立节点
   • 配合token机制或版本号防止锁失效后的操作冲突
   • 设置合理的锁超时时间和重试策略

红锁提供了一种折中的分布式锁解决方案，但在极端情况下仍可能出现问题，应根据业务特点谨慎选择分布式锁的实现方式。
程序员面试资料大全｜各种技术书籍等资料-1000G