Redis集群不支持跨槽位Lua脚本原子执行，所有key必须位于同一slot，可通过哈希标签（如{1001}）强制路由、客户端ASKING模式及KEYS参数传入确保合规。
Redis集群下Lua脚本执行失败：MOVED重定向导致原子性丢失
Redis集群不支持跨槽位的Lua脚本原子执行——这是硬限制，不是配置问题。当你在脚本里读写多个key，而它们落在不同slot（比如 user:1001 和 order:2001），EVAL 会直接报错 ERR Lua script attempted to access a non-local key，或者被客户端自动重定向后实际执行两次（破坏原子性）。
根本原因是：集群模式下每个节点只负责一部分slot，Lua脚本必须在目标key所在节点上执行，且所有key必须属于同一slot。Redis不会帮你做跨节点协调。
- 检查key所属slot：用
CLUSTER KEYSLOT <key>手动验证，或确保所有key都带相同哈希标签（如{user1001}:profile和{user1001}:settings） - 客户端必须开启
ASKING模式（Jedis/Lettuce等主流客户端已内置处理，但需确认版本 ≥ 3.0） - 避免在脚本中硬编码key名；用
KEYS[1]、KEYS[2]传入，并保证调用时所有key都在同一slot
用哈希标签（Hash Tag）强制多key落同一slot
这是最常用也最可控的解法。Redis对key计算slot时，只取花括号 {} 包裹的部分（且只取第一个有效括号对）作为哈希输入。例如：user:{1001}:profile 和 user:{1001}:orders 都会落到同一个slot。
注意：括号必须成对，且不能嵌套；{user1001}::cache 和 user1001:{cache} 是等效的，但 user{1001}::cache 会被截为 {1001}，而 user{1001 不合法（无闭合）会导致整个key参与哈希，行为不可控。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 服务端生成key时统一加tag，比如用户维度数据全部用
{uid}前缀 - 不要依赖业务ID自然分布——哪怕ID连续，也不代表slot连续；必须显式控制
- 哈希标签会降低slot分散度，极端情况下可能造成单slot热点（比如所有订单都打到
{1}），上线前用redis-cli --cluster check观察slot负载
Lua脚本里访问复杂结构：hgetall / zrange / json.get 的坑
集群模式下，只要key在同一slot，HGETALL、ZRANGE、JSON.GET（需RedisJSON模块）这些命令本身没问题。但容易忽略两点：
-
redis.call()中不能混用本地和非本地key——即使你用了哈希标签，脚本里仍要确保所有KEYS[i]都传了，不能在脚本里拼接新key字符串再调用（比如"temp:"..KEYS[1]） - 如果用RedisJSON，
JSON.GET user:{1001} $.name可以，但JSON.ARRAPPEND user:{1001} $.tags "new"必须确保该key存在且是数组，否则报错中断脚本，且事务不回滚（Lua无真正事务，只有“全执行”或“全不执行”，但失败时已执行的命令不会撤销） - 大体积响应（如
HGETALL返回几千个field）会阻塞当前节点，建议在脚本里用HSCAN分页，或提前约定只读关键字段
替代方案：为什么有时该放弃Lua，改用应用层锁+重试
当操作涉及多个高竞争key、或需要条件判断后再写（比如“余额够才扣减”），硬塞进一个Lua脚本反而难维护、难测试、且一旦出错无法细粒度定位。这时候不如退一步：
- 用
SET resource:{1001} "locked" NX PX 5000做租约锁，失败则重试（注意NX+PX必须一起用，避免死锁） - 锁住后，在应用代码里分步读-判-写，最后
DEL resource:{1001}；用EVALSHA预加载脚本提升性能 - 如果怕网络分区导致锁残留，可引入Redis Redlock或外部协调服务（如etcd），但多数场景本地锁+超时足够
哈希标签和Lua不是银弹。真正的难点从来不在语法，而在如何让业务语义适配分布式约束——比如把“用户+订单+库存”三者强绑定到同一slot，有时意味着要重构领域模型，而不是改几行脚本。
