redlock是hyperf生产环境防超卖的底线要求，因单节点redis锁无法应对实例宕机或主从切换；需用封装sdk如hyperf-wise-locksmith实现多节点并行请求、多数派投票及安全释放。
Hyperf 项目里直接用 SET NX PX 做单节点 Redis 锁，能防大部分并发，但扛不住 Redis 实例宕机或主从切换——这时候 Redlock 不是“更高级的选配”，而是生产环境防超卖的底线要求。
Redlock 在 Hyperf 里为什么不能直接用 hyperf/redis 自带命令
Hyperf 的 hyperf/redis 提供的是单客户端连接，而 Redlock 算法要求：向 ≥3 个独立 Redis 节点（非集群模式）并行发锁请求，多数派（N/2+1）返回成功才算加锁成功。原生 Redis 类不支持多实例协调、超时控制、重试策略和投票逻辑。
常见错误现象：
- 手写循环调用多个
$redis->set()，但没做失败重试和多数派校验，结果变成“伪 Redlock” - 用
phpredis的多连接手动拼 Redlock，却忽略时钟漂移补偿（drift计算），导致锁实际有效期缩水 - 锁释放时只删自己连的那个节点，其他节点残留锁 key，引发后续死锁
正确做法是用封装好的 Redlock SDK，比如 pudongping/hyperf-wise-locksmith 或官方推荐的 malkusch/lock + 自定义 Redlock 适配器。前者开箱即用，后者语义更清晰。
用 hyperf-wise-locksmith 快速接入 Redlock
这个库已内置 redLock() 方法，底层自动管理多个 Redis 连接、投票、续期和安全释放。
安装与配置：
- 执行
composer require pudongping/hyperf-wise-locksmith-vvv - 在
config/autoload/redis.php中定义至少 3 个独立 Redis 配置（不能是 cluster 或 sentinel 别名）：
'redlock_nodes' => [ 'redis1' => ['host' => '10.0.1.10', 'port' => 6379, 'database' => 0], 'redis2' => ['host' => '10.0.1.11', 'port' => 6379, 'database' => 0], 'redis3' => ['host' => '10.0.1.12', 'port' => 6379, 'database' => 0], ],
业务代码中使用：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
$res = $this->locker->redLock('inventory:1001', function () use ($qty) {
$stock = Inventory::find(1001);
if ($stock->qty decrement('qty', $qty);
return true;
}, 10); // 10秒锁过期
注意点：
- 第三个参数是锁 TTL（秒），不是毫秒；内部会自动转成
PX毫秒并加入 drift 补偿 - 回调函数内不要 sleep 或阻塞协程，否则 Redlock 的租约时间可能耗尽
- 该方法默认尝试 3 次，每次间隔 100ms，可通过第四个参数覆盖
Redlock 的锁续期（renew）必须手动触发
Redlock 规范本身不支持自动续期，因为续期操作需重新走一遍多数派投票，代价高。Hyperf 场景下，如果你的扣减逻辑可能超过锁 TTL（比如要查库存、校验优惠券、调外部支付接口），就必须显式续期。
使用 hyperf-wise-locksmith 的续期方式：
- 先用
acquire()获取锁并拿到$lockId - 在业务逻辑中定时调用
renew($lockId, $ttl)，例如每 3 秒续一次 10 秒锁 - 务必在
finally块里调用release($lockId)，避免协程异常退出后锁残留
错误示例：$this->locker->redLock(...) 包裹整个长流程，却不续期 —— 一旦执行超时，锁自动释放，其他协程趁虚而入，超卖就发生了。
Redlock 不是银弹：它解决什么，又不解决什么
Redlock 解决的是「Redis 单点故障下的锁可靠性」，但它无法规避以下问题：
- 客户端时钟严重漂移（>100ms）：Redlock 依赖各节点本地时间，若某台机器 NTP 失效，会导致锁提前过期
- 网络分区（如 redis1/redis2 之间断连）：此时多数派无法形成，加锁失败，业务需降级处理（比如走数据库悲观锁）
- 锁粒度太粗：用
inventory:1001锁整条商品记录，但实际只需锁某个 SKU，会人为扩大竞争面
真正压测下来，Redlock 的加锁耗时比单节点高 3–5 倍（三次网络往返），所以别在高频短操作里滥用。库存扣减这类关键路径，Redlock 是必要成本；而日志落盘、缓存刷新这类场景，单节点锁 + 合理 TTL 更合适。
