PHP用Redis锁防重复调用服务_PHPRedis锁防重调用法【防重】

1次阅读

redis SETNX锁失效的根本原因是未保障原子性及过期机制,正确做法是用SET key value NX EX seconds一条命令设锁,value用唯一标识,解锁用lua脚本校验后删除,并配合指数退避重试。

PHP用Redis锁防重复调用服务_PHPRedis锁防重调用法【防重】

redis SETNX 实现锁时为什么总失效

根本原因不是命令用错,而是没处理好原子性边界和过期时间。比如只用 SETNX 设键,却忘了设过期,一旦进程崩溃或网络中断,锁就永远卡住;或者先 SETNXEXPIRE,中间若服务挂了,锁就无过期机制。

正确做法是用 SET key value NX EX seconds 一条命令完成「不存在才设值 + 自动过期」,phpRedis 中对应 set($key, $value, ['nx', 'ex' => $ttl])。其中 $value 必须是唯一标识(如 uniqid('', true)),后续解锁时靠它校验所有权,避免误删别人持有的锁。

  • 不要用 get + setsetnx + 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 类自动解决。

text=ZqhQzanResources