Redis Cluster要求Lua脚本所有KEYS必须同slot，否则报CROSSSLOT错误；解决方法是用{}哈希标签统一关键字段（如{lock:order:123}），且KEYS须显式传入、不可脚本内拼接。
Redis Cluster对Lua脚本的key分布有硬性限制
Redis Cluster不支持跨slot执行Lua脚本。如果你的锁key（如lock:order:123）和看门狗续期用的channel key（如redisson_lock__channel:{lock:order:123}）落在不同slot，EVAL会直接报错CROSSSLOT Keys in request don't hash to the same slot。
解决办法只有一个：强制所有相关key路由到同一个slot。必须用{...}哈希标签包裹锁名，且所有脚本内涉及的key都得套同一组花括号。
-
KEYS[1]写成{lock:order:123}，不是lock:order:123 -
KEYS[2]（比如通知channel）必须是redisson_lock__channel:{lock:order:123}，花括号位置和内容要完全一致 - 客户端生成锁key时就得带
{...}，不能等脚本里再拼——否则JedisCluster或Lettuce会在发命令前就按原始key计算slot，导致路由失败
JedisCluster执行Lua脚本必须用evalSha而非eval
JedisCluster的eval()方法底层会尝试把脚本广播到所有节点，根本不会做slot路由，结果是随机失败或抛JedisClusterException。正确做法是先用scriptLoad()把脚本加载到所有master节点，拿到sha1值，再用evalSha()并显式传入目标节点的key（即带{...}的锁名）。
关键点：
- 脚本加载只需一次，可放在应用启动时；重复
scriptLoad()不会报错，但浪费连接 -
evalSha()调用时，keys参数里的第一个key决定路由节点，它必须含有效哈希标签 - 别依赖
ScriptingCommands.eval()这类泛型接口——Cluster模式下它们往往绕过slot校验，行为不可控
Lua脚本里不能用redis.call("GET")去校验value
在Cluster中，redis.call("GET", KEYS[1])看似安全，但一旦锁key过期被自动删除，GET返回false，后续DEL操作就变成无条件删除——可能误删别人刚加上的锁。
真正安全的做法是用redis.call("HEXISTS", KEYS[1], ARGV[1])（假设你用Hash存clientID）或者更直接地：if redis.call("GET", KEYS[1]) == ARGV[1] then ...，但必须配合原子性保障：
- 整个判断+删除逻辑必须包在单个
EVALSHA里，不能拆成两次网络请求 - 如果用Hash结构（如Redisson），
HEXISTS比GET多一次字段检查，但避免了字符串比较的隐式类型转换风险 - 别在脚本里写
redis.call("EXISTS", KEYS[1])再单独DEL——这俩命令之间存在竞态窗口
锁超时时间必须小于业务最长执行时间，但不能靠脚本硬编码
脚本里写死ARGV[2]为30000毫秒很危险。集群环境下网络抖动、GC停顿都可能导致业务实际耗时远超预期，而Lua脚本无法动态感知当前线程状态。
可行方案：
- 客户端传入
ARGV[2]时，取值为业务预估最大耗时 × 1.5，留出缓冲余量 - 若需自动续期（看门狗），必须由客户端独立线程完成，不能塞进Lua脚本——脚本执行完就结束了，没法长期驻留
- Cluster节点间时钟不同步时，
PTTL返回值可能不准，所以解锁逻辑不要依赖剩余时间判断是否过期，只认clientID匹配
最易被忽略的一点：Cluster的readonly slave节点默认不执行EVALSHA，必须确保所有evalSha()调用都打到master节点——JedisCluster的evalSha()默认满足这点，但自定义路由逻辑时得手动校验isMaster()。
