redis 6.0集群中eval/evalsha严禁跨槽执行，报crossslot错误是硬性设计限制；唯一解法是用{}哈希标签使所有keys参与哈希的部分相同，确保落同一slot。

Redis 6.0 集群中根本不存在“高效调度跨槽 Lua 脚本任务”这回事——EVAL 和 EVALSHA 在集群模式下严格禁止跨槽执行，报 CROSSSLOT 错误不是性能问题，是设计硬限制。所谓“调度”，本质是规避错误，而非优化执行。

为什么 EVAL 在 Redis 6.0 集群里必然报 CROSSSLOT

集群把 16384 个 slot 分散到多个节点，每个 key 按 CRC16(key) % 16384 算出归属 slot；Lua 脚本执行前，Redis 会检查所有 KEYS 参数是否落在同一 slot，只要有一个不同，立刻拒绝，连脚本解析都不做。错误信息典型为：(error) CROSSSLOT Keys in request don't hash to the same slot。

这不是客户端能绕过的逻辑，Jedis、Lettuce 等主流客户端在调用前就会调用 JedisClusterCRC16.getSlot() 或等效方法校验，不一致直接抛 JedisClusterException。

常见踩坑点：

• 本地单机 Redis 测通了，一上集群就崩——单机不校验 slot，掩盖了 key 设计缺陷
• 以为 EVALSHA 是“绕过方案”——它只发 sha1，校验逻辑和 EVAL 完全一致，照样报错
• 在脚本里拼接新 key，比如 KEYS[1] .. ":counter"——这个 key 不在 KEYS 数组里，属于“非本地 key”，运行时报 ERR Lua script attempted to access a non-local key

必须用 {} 哈希标签对齐所有 KEY 的 slot

这是唯一被官方支持、无需改集群配置、不依赖客户端分片逻辑的解法：Redis 计算 slot 时，只取第一个成对 {} 内的内容参与 CRC16，其余部分忽略。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

正确写法示例（都强制落到同一 slot）：

• user:{1001}:profile
• cart:{1001}:pending
• order:{1001}:items

关键约束：

• 所有要传入 KEYS 的 key，必须显式带相同哈希标签，不能靠脚本内构造
• 嵌套 {} 只认最内层第一对，user:{abc{def}:xyz 实际取 def 哈希
• {} 不能为空，user:{}:profile 会被当成整个字符串哈希，失去控制力
• 服务端写入 key 时就必须带 tag，别等调用脚本才想怎么拼

上线前必须验证 slot 是否真对齐

光靠命名规则不验证，扩容或 CLUSTER SETSLOT 后可能突然失败。必须实测：

• 用 redis-cli -c 连集群，执行 CLUSTER KEYSLOT user:{1001}:profile 和 CLUSTER KEYSLOT cart:{1001}:pending，确认返回值一致
• 用 redis-cli --cluster check <host>:<port></port></host> 查看 slot 分布，确认这些 key 对应的 slot 确实由同一节点负责
• 若业务 key 本身不含稳定 ID（如用 UUID），必须在应用层提取/约定一个稳定字段塞进 {}，例如从 order:abc-def-ghij 中提取 abc 作为 tag

最容易被忽略的是：Hash Tag 只解决 key 分布，不解决命令兼容性。像 SCAN、KEYS、MGET（无 tag 时）在集群里仍受限或禁用，别指望靠 tag “激活”它们。