ThinkPHP 默认不支持 RedisRedLock，因其设计面向通用单实例缓存，而RedLock需多独立节点协同、quorum判定及复杂容错逻辑，远超框架抽象范围。
RedisRedLock 不是 ThinkPHP 原生支持的锁机制，也不是 Redis 官方标准命令；它属于一种多节点容错型分布式锁算法（由 Redis 作者 Antirez 提出），而 ThinkPHP 默认的 Cache::store('redis') 或 think\facade\Cache 只提供单实例 Redis 锁能力。直接套用 RedLock 算法在 TP 中需手动实现，且多数业务场景并不需要。
为什么 TP 默认不支持 RedLock？
ThinkPHP 的缓存驱动设计面向通用性，Cache::lock() 或 set(..., ['NX','PX'=>...]) 都只操作一个 Redis 实例。而 RedLock 要求：
- 至少 3 个相互独立的 Redis 主节点（无主从关系）
- 客户端需向多数节点（N/2+1）成功 set key 才算加锁成功
- 所有节点锁的过期时间、key 和唯一 value（如 UUID）必须严格一致
- 解锁时需逐个向所有节点发 del（或 Lua 校验后删）
这超出框架缓存层抽象范围，TP 没有内置多连接协调、超时熔断、quorum 计数等逻辑。
Cache::store('redis') 加锁为什么不能直接当 RedLock 用？
常见误用是这样写：
立即学习“PHP免费学习笔记（深入）”；
$key = 'order:pay:' . $orderNo;
if (Cache::store('redis')->set($key, $requestId, ['NX', 'PX' => 10000])) {
// do something
Cache::store('redis')->delete($key);
}问题在于：
-
set(..., ['NX','PX'=>...])是原子的，但仅限单节点 —— 若该 Redis 实例宕机，锁即失效，无法降级到其他节点 - 没有 value 校验的
delete()存在误删风险（别人续了锁，你删掉了） - 没处理网络分区、GC 停顿导致锁实际持有时间 > 设置 TTL 的情况
- TP 的
Cachefacade 不暴露底层 Redis 连接实例，无法手动调用多个Redis对象
真要用 RedLock，得绕开 TP 缓存层自己写
核心是：自己管理多个 Redis 实例，封装 quorum 判定逻辑。示例关键点：
- 用
new Redis()分别连 3 个独立地址，不要复用Cache::store() - 生成全局唯一
$requestId = bin2hex(random_bytes(16))，所有节点用同一个 - 对每个节点执行：
$redis->set($key, $requestId, ['NX','PX'=>10000])，记录成功数 - 成功数 ≥ 2（3 节点时）才算加锁成功，并立刻记录「实际获取到的最短剩余 TTL」用于续期参考
- 解锁必须用 Lua：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end，逐节点执行 - 加锁后建议启动一个守护协程（或定时器）做自动续期，防止业务执行超时导致锁提前释放
注意：RedLock 在 Redis Cluster 模式下不适用 —— 因为 key 可能被重定向，quorum 判定失效。
大多数 TP 项目其实该用单节点 + Lua 安全锁
95% 的并发冲突场景（如库存扣减、订单幂等、防重复提交），用单 Redis 实例配合以下两点就足够健壮：
- 加锁用
$redis->set($key, $requestId, ['NX','PX'=>10000]) - 解锁用 Lua 脚本校验 value 再删（ThinkPHP8 的
RedisMutexLock::releaseDistributedLock()就是这么干的）
比 RedLock 更轻、更可控，也规避了多节点运维复杂度和时钟漂移问题。真正需要 RedLock 的，往往是金融级跨机房强一致性系统 —— 那种项目通常也不会只用 TP 单框架兜底。
RedLock 的最大陷阱，是让人误以为“用了就绝对安全”。实际上，它的安全性高度依赖节点数量、网络稳定性、客户端时钟精度，而这些在中小业务的 Redis 部署中很难保障。先跑通单节点 Lua 锁，再评估是否真有必要上 RedLock。
