RedisRedLock 在 PHP 中不能直接用 SETNX 模拟，因其无原子过期能力，单实例故障即失效；RedLock 要求至少3个独立主节点并行加锁，成功数超半数且总耗时小于锁过期时间才算获取成功。
RedisRedLock 在 PHP 中为什么不能直接用 SETNX 模拟
因为 SETNX 本身不具备原子性过期能力，单独用它加锁后若进程崩溃，锁无法自动释放；而 SET key value EX seconds NX 虽能解决原子设值+过期，但单 Redis 实例故障会导致锁失效，违背 RedLock「多数派存活才认为锁有效」的设计前提。RedLock 的核心不是「怎么设一个锁」，而是「怎么在多个独立 Redis 实例上协调出一个容错锁」。
常见错误是只连一个 Redis，或用 Redis Cluster 代替 RedLock —— Cluster 是数据分片系统，节点间不保证强一致，WAIT 命令也无法覆盖所有故障场景，不符合 RedLock 对「N 个独立主节点」的要求。
实操建议：
- 至少部署 3 个（推荐 5 个）完全独立的 Redis 主节点（无从、无哨兵、无集群），网络隔离、进程隔离
- PHP 客户端必须支持连接池和超时控制，避免某个实例卡住拖垮整体流程
- 每次加锁需向全部 N 个实例并行发送
SET key value EX seconds NX，记录成功数量 - 只有成功数 > N/2（即多数派）且总耗时
PHP 使用 phpredis 实现 RedLock 的关键参数控制
phpredis 扩展本身不内置 RedLock，需手动封装。重点不在连接逻辑，而在「时间窗口」和「重试策略」的把控。
立即学习“PHP免费学习笔记（深入）”；
容易踩的坑：
-
setOption(REDIS_OPT_READ_TIMEOUT)和setOption(REDIS_OPT_CONNECT_TIMEOUT)必须显式设为 10–50ms 级别，否则单个慢实例会拉长整体耗时，导致「多数派达标但已超时」 - 不能用
getLastError()判定失败：网络超时、连接拒绝、协议错误都会返回不同错误码，应统一以「命令未返回 OK」为失败依据 - 解锁时不能简单遍历所有实例执行
DEL：要先GET校验 value 是否匹配（防误删），且忽略DEL返回的0或错误（部分实例可能已失联）
示例片段（加锁核心逻辑）：
foreach ($redisInstances as $redis) {
$result = $redis->set($lockKey, $lockValue, ['nx', 'ex' => $ttl]);
if ($result === true) {
$acquired++;
}
}
if ($acquired > count($redisInstances) / 2 && (microtime(true) - $startTime) < $ttl / 2) {
return $lockValue; // 加锁成功
}RedLock 在 PHP-FPM 场景下的生命周期管理难点
PHP 是无状态短生命周期语言，FPM worker 处理完请求就可能被回收，但 RedLock 的锁续期（renew）和自动释放机制无法依赖 GC 或析构函数——__destruct() 不保证执行时机，register_shutdown_function() 在超时 kill 时也无效。
这意味着：你不能指望「脚本结束自动解锁」。必须主动控制。
实操建议：
- 锁必须绑定明确的业务上下文（如订单号、用户 ID），并在业务逻辑出口处显式调用
unlock() - 绝不依赖
atexit或异常捕获兜底：PHP 异常不捕获致命错误（E_ERROR）、信号中断（SIGKILL） - 设置锁 TTL 时，必须大于「最长可能执行路径耗时 × 1.5」，并配合看门狗检查：例如用
pcntl_alarm()或定时轮询GET锁值判断是否仍属当前进程 - 若使用 Swoole，可借助
Swoole\Timer::tick()做后台续期，但注意多协程共享锁变量需加Channel或Atomic同步
RedLock 和数据库乐观锁、ZooKeeper 的取舍边界
RedLock 不是万能锁方案。当你的服务已重度依赖 MySQL，且并发冲突集中在某几张表的某几行，用带 WHERE version = ? 的 UPDATE + 重试，比引入 5 个 Redis 实例更轻量、更可控。
ZooKeeper 的 create(/lockpath, EPHEMERAL) 能提供真正的强一致性，但运维成本高，PHP 生态原生支持弱（需 zk 扩展 + C 依赖），且网络分区时可能出现脑裂。
RedLock 真正适用的场景很窄：
- 跨多个微服务（PHP/Java/Go 混合）需要共享同一把锁
- 锁粒度细、持有时间短（
- 已有稳定 Redis 运维能力，能保障 N 个实例独立部署与监控
如果只是防止同一用户重复提交表单，用 session + 时间戳 + redis INCR 就够了；非要上 RedLock，反而把简单问题复杂化。
