Redis SETNX锁失效的根本原因是未保障原子性及过期机制，正确做法是用SET key value NX EX seconds一条命令设锁，value用唯一标识，解锁用Lua脚本校验后删除，并配合指数退避重试。
Redis SETNX 实现锁时为什么总失效
根本原因不是命令用错，而是没处理好原子性边界和过期时间。比如只用 SETNX 设键，却忘了设过期，一旦进程崩溃或网络中断，锁就永远卡住；或者先 SETNX 再 EXPIRE，中间若服务挂了，锁就无过期机制。
正确做法是用 SET key value NX EX seconds 一条命令完成「不存在才设值 + 自动过期」，PHPRedis 中对应 set($key, $value, ['nx', 'ex' => $ttl])。其中 $value 必须是唯一标识（如 uniqid('', true)），后续解锁时靠它校验所有权，避免误删别人持有的锁。
- 不要用
get+set或setnx+expire两步操作 -
$ttl建议设为业务执行最大耗时的 2–3 倍，太短易误释放，太长会阻塞后续请求 - 锁 key 最好带业务上下文，例如
"lock:order:create:{$userId}"，避免全局冲突
解锁必须用 Lua 脚本保证原子性
单纯 GET 判断再 DEL 是典型竞态：A 进程读到自己的 value，正要删，B 进程已超时释放并重新持锁，此时 A 的 DEL 就把 B 的锁干掉了。
唯一安全解法是用 Lua 脚本在 Redis 端完成「判断 value 相等再删」，PHP 中这样写：
立即学习“PHP免费学习笔记（深入）”；
public function unlock($key, $value) {
$script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
return $this->redis->eval($script, [$key], [$value]);
}注意：eval() 返回 1 表示删除成功，0 表示未操作（可能锁已过期或被覆盖），不能忽略返回值直接认为解锁成功。
- 别用 PHP 的
get+del组合，这是最常见误用 - 脚本里必须用
KEYS[1]和ARGV[1]，不能拼接字符串，否则不支持集群模式 - 如果用的是 phpredis 扩展，确保版本 ≥ 5.0，旧版
eval在集群下行为不可靠
重试逻辑要带退避，别死循环 GET
抢锁失败后，立刻重试只会加剧 Redis 压力，还可能触发限流或连接打满。真实场景中应采用指数退避（exponential backoff）+ 随机抖动。
例如初始等待 10ms，每次失败翻倍，上限 200ms，再加 ±20ms 随机误差：
$wait = mt_rand(8, 12); // 第一次 8–12ms
for ($i = 0; $i < $maxRetries; $i++) {
if ($this->tryLock($key, $value, $ttl)) {
return true;
}
usleep($wait * 1000);
$wait = min($wait * 2, 200); // 翻倍，但不超过 200ms
}- 总重试次数建议 ≤ 5 次，超过说明业务异常或锁设计不合理
- 别用
while(true)不设上限，容易卡死协程或耗尽 CPU - 如果锁等待时间接近业务超时阈值，应直接返回失败，而不是硬扛
分布式环境下要注意 Redlock 不适用多数 PHP 场景
Redlock 理论上更安全，但它依赖多个独立 Redis 实例、严格时间同步和多数派协议，在 PHP 单进程模型 + 主从架构 + 运维简单性约束下，实际收益远低于复杂度成本。
绝大多数 PHP 服务用单节点 Redis + 正确的 SET + Lua 解锁 + 合理 TTL 就足够。真正需要 Redlock 的场景极少——比如金融级资金幂等，且已部署至少 5 个跨机房 Redis 实例。
- 别为了“看起来更安全”引入 Redlock 客户端库，反而增加故障点
- 主从切换时，Redis 复制是异步的，
SET成功后主挂掉、从升主，可能丢锁——这是 Redis 本身限制，不是锁代码能解决的 - 如果业务对一致性要求极高，锁只是辅助，最终仍需数据库唯一索引或状态机校验
锁的难点不在实现几行代码，而在于理解「谁该负责清理」「超时和业务耗时如何对齐」「失败后是重试还是降级」——这些没法靠封装一个 RedisLock 类自动解决。
