Redis红锁（Redlock）是一种分布式锁算法，通过在多个独立Redis节点上获取锁来实现高可用性和一致性。核心原理是：客户端需要在N个（建议奇数，如5个）Redis master节点上依次尝试获取锁，每个节点设置相同的锁超时时间（TTL），只有在大多数节点（N/2 + 1）上成功获取锁后，才认为锁获取成功。释放锁时，需要在所有节点上释放，即使部分节点未获取成功。这解决了单点Redis的故障问题和并发冲突，确保在网络分区或节点故障时，锁不会被错误授予。

Redlock算法步骤详解

1. 获取当前时间戳。2. 依次在N个Redis节点上执行SET key value NX PX ttl，如果成功，记录时间。3. 如果在至少N/2+1个节点上成功，且总耗时小于TTL，则锁获取成功。4. 释放时，向所有N个节点发送释放命令。Redlock通过多数派（quorum）机制避免脑裂，确保数据一致性，即使少数节点故障，系统仍可靠。

Redlock解决并发冲突的核心机制

传统单Redis锁易受时钟漂移和网络延迟影响，导致锁过期后多个客户端同时认为锁可用，引发并发冲突。Redlock使用多个独立节点，每个节点有独立时钟和TTL，客户端只在多数节点成功且总延迟<TTL时认为成功，避免了单点时钟问题。同时，锁值包含唯一随机值，防止误释锁，确保只有锁持有者能释放。

Redlock实现代码示例（Java）

使用Redisson库简化实现：RedissonRedLock redLock = redisson.getRedLock(redissonLock1, redissonLock2, redissonLock3); redLock.lock(); try { //业务逻辑 } finally { redLock.unlock(); } 这封装了多节点加锁逻辑，自动处理quorum和释放。

Redlock vs 单节点锁的痛点对比

单节点锁：节点故障锁不可用，重启后可能丢失锁。Redlock：多数节点存活即可，故障节点不影响。并发冲突：单节点依赖单一TTL易漂移，Redlock多数派投票确保一致性。数据一致性：Redlock防止少数派错误授权锁，适用于高并发场景如秒杀、库存扣减。

Redlock的网络假设与局限

Redlock假设异步网络模型，节点间无强同步时钟。痛点：如果网络延迟过大或时钟漂移严重，可能仍有小概率失效。解决方案：缩短TTL、增加节点数、使用clock服务如PTP。实际生产中，结合ZooKeeper或etcd作为备选。

FAQ

Q: Redlock需要多少个节点？
A: 建议5个独立Redis master，quorum为3。

Q: Redlock如何处理节点故障？
A: 只要多数节点可用，锁仍可获取/续期，故障节点自动忽略。

Q: Redlock有性能开销吗？
A: 是的，多节点RTT延迟增加，但远低于数据库锁。

Q: 如何实现自动续期？
A: 使用watchdog线程，每TTL/3检查并续期锁。