Redis集群中如何实现分布式锁_使用Redlock算法在多主节点上安全加锁-Redis-PHP中文网

redis官方不推荐redlock，因其依赖时钟同步且在集群模式下前提不成立；单实例set nx px+唯一value+lua原子解锁更安全可靠。

redis集群中如何实现分布式锁_使用redlock算法在多主节点上安全加锁

Redlock 不是 Redis 官方推荐的分布式锁方案

Redis 官方文档明确指出：Redlock 在实际部署中难以保证安全性，尤其当时钟漂移、网络分区或节点故障未被精确建模时，会出现多个客户端同时持有锁的情况。它依赖所有主节点独立运行且时钟基本同步——但真实环境里，NTP 调整、虚拟机暂停、容器调度都可能造成 clock drift 超出容忍范围（通常设为 50ms）。如果你的集群启用了 cluster mode 或哨兵模式，Redlock 的“向 5 个独立实例发请求”前提根本不存在：你无法绕过集群路由逻辑直接操作底层主节点。

用 `SET key value NX PX timeout` 在单个 Redis 实例上实现可靠加锁

绝大多数业务场景下，真正需要的是「单点强一致性锁」，而非跨多主的“高可用假象”。只要这个 Redis 实例本身高可用（如哨兵或 Cluster 中的某个稳定主节点），配合正确的释放逻辑，就足够安全：

NX 确保只有 key 不存在时才设置成功，避免覆盖其他客户端的锁
PX 必须指定毫秒级过期时间，防止死锁；值建议设为执行临界区操作的预期最大耗时 × 2
value 必须是唯一随机字符串（如 UUID），后续解锁时用 EVAL 脚本比对，杜绝误删他人锁

解锁脚本必须原子执行：

if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

集群环境下如何选对锁的 key 所在节点

Redis Cluster 会根据 key 的 slot 分配到不同节点。若直接对任意 key 加锁，SET 可能被重定向（MOVED 或 ASK 错误），导致锁分散在多个节点，失去互斥性。正确做法是强制让锁 key 落在同一个 slot：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

用 {...} 包裹 key 的一部分，例如锁 key 写成 lock:{order:12345}，确保所有同类锁 hash 到同一节点
避免使用自增 ID、时间戳等高散列 key，否则锁会打散到整个集群，无法保障原子性
如果业务天然按用户 ID 隔离（如 lock:{uid:789}），那完全可行；但如果要锁全局资源（如“库存扣减开关”），就得预设一个固定 slot 键，比如 lock:{global_inventory}