Redlock在PHP中不能直接用phpredis原生命令实现，因其要求多实例独立加锁、严格对齐超时、多数派成功才算有效，而phpredis的set()缺乏NX/PX原子语义判别、无内置重试与时钟漂移补偿，易因时间差或网络超时导致“假成功”。
Redlock在PHP中为什么不能直接用phpredis原生命令实现
因为Redlock不是单次SET命令能搞定的——它要求多个Redis实例独立加锁、超时时间严格对齐、多数派成功才算获取锁。而phpredis的set()不支持NX PX原子语义与返回值区分（比如是否真正设置了key），且没有内置重试逻辑和时钟漂移补偿。
常见错误是直接循环调用$redis->set($key, $val, ['NX', 'PX' => $ttl])，但忽略两点：一是不同Redis节点系统时间可能差几十毫秒，二是某次网络超时后无法判断该节点是否已写入成功，导致“假成功”。
- 必须用
SET $key $val NX PX $ttl完整命令字符串，靠返回值"OK"判成功，不能依赖布尔返回 - 每个节点操作需记录本地发起时间
microtime(true)，而非用服务端TIME命令——后者不可信 - 最终锁有效时间 =
min(各节点TTL) - 总耗时 - 时钟漂移余量（通常设为2ms）
用composer require predis/predis还是phpredis扩展
predis更适配Redlock实现，因为它的executeRaw()能精准发原始命令，且ConnectionInterface抽象让多实例切换干净；而phpredis虽快，但要自己封装连接池、异常重连、命令构造，容易漏掉READONLY错误或MOVED重定向处理。
性能差异在单次锁操作里几乎感知不到（微秒级），但predis的可维护性优势明显：比如自动识别CLUSTER模式下重定向，或对ERR响应做统一解析。
- 若已深度绑定
phpredis，可用Redis::rawCommand()替代，但必须手动检查返回值类型（字符串"OK"vsfalsevsnull） - 避免混用两种客户端——同一进程内不要既用
predis又用phpredis操作同一组Redis节点，连接状态和超时策略不一致 -
predis默认开启tcpKeepAlive，对长连接稳定性有帮助；phpredis需显式调用setOption(Redis::OPT_TCP_KEEPALIVE, 1)
如何防止Redlock被误释放——关键在unlock的原子性校验
释放锁绝不能只删key：$redis->del($key)会误删别人持有的锁。必须用Lua脚本保证“校验value再删除”，否则A刚过期、B还没来得及续租，C就删了key并抢到锁，A后续的DEL会干掉C的锁。
标准Lua脚本长这样：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end。注意ARGV[1]必须是加锁时生成的唯一随机值（如bin2hex(random_bytes(16))），不能用进程PID或时间戳——它们不全局唯一。
- 所有加锁客户端必须用相同方式生成
lock_value，建议封装成LockToken::generate()静态方法 - 解锁时若Lua返回
0，说明锁已被别人覆盖，此时应记录告警而非报错——业务层需容忍“解锁失败但实际已失效” - 别在
__destruct()里自动unlock：PHP垃圾回收时机不确定，可能进程退出前锁早过期了，反而造成误删
分布式环境下clock drift怎么量化并防御
Redis服务器之间时间差就是clock drift，它直接吃掉你的锁有效期。实测发现，即使NTP同步，三台机器间仍可能有3~8ms偏差。Redlock论文建议预留2ms余量，但生产环境建议至少留5ms。
更稳妥的做法是启动时探测：向所有Redis节点发TIME命令，取最大最小值差作为初始drift，后续每次加锁都动态叠加这个值。但注意TIME不准——它返回的是Redis进程启动后秒数，不是系统时间。
- 真实可行的方案：在应用启动时，用
microtime(true)分别请求每个节点的INFO（带时间戳字段），再比对自身时钟，得出每节点的偏移量数组 - 每次加锁后，用
microtime(true)减去发起时间，得到实际耗时；再减去预估drift，才是安全的剩余TTL - 如果某节点响应超时（比如>50ms），直接剔除——它已不可信，不算进quorum统计
Redlock不是银弹。当网络分区发生时，它只能保证“最多一个客户端拿到锁”，但无法阻止客户端因延迟收到响应而重复执行。真正的安全边界在业务层：锁只是减少冲突概率，幂等性设计才是底线。
