redis集群中eval报crossslot错误是因为脚本涉及的多个key未落在同一slot；解决方法是使用哈希标签{}使相关key强制映射到相同slot，如user:{1001}:profile。

为什么 EVAL 在 Redis 集群里会报 CROSSSLOT 错误

Redis 集群把 key 按 slot 分散到不同节点，而 Lua 脚本执行时必须保证所有涉及的 key 都落在同一个 slot 上——否则集群无法确定该脚本该发给哪个节点执行。EVAL 本身不校验 key 的 slot 分布，等真正执行时才发现跨 slot，就直接报 CROSSSLOT Keys in request don't hash to the same slot。

常见错误现象：EVAL "return redis.call('get', KEYS[1])" 1 user:1001 没问题，但 EVAL "return {redis.call('get', KEYS[1]), redis.call('get', KEYS[2])}" 2 user:1001 order:999 很可能崩，因为两个 key 哈希后大概率不在同一 slot。

• 使用场景：批量读写多个 key、原子性计数+更新、带条件的多 key 判断
• 根本限制：集群模式下，EVAL 和 EVALSHA 只接受所有 KEYS 参数都属于同一 slot 的脚本
• 不是 Lua 写得不对，是 key 设计没对齐 slot 规则

如何让多个 key 落在同一个 slot（哈希标签）

Redis 支持用花括号 {} 定义哈希标签，只有括号内的部分参与 slot 计算。比如 user:{1001}:profile 和 user:{1001}:settings 会落到同一 slot，因为实际参与哈希的是 1001。

这是唯一被官方支持的、能让多个 key 强制同 slot 的方法，不用改集群配置，也不依赖客户端分片逻辑。

• 正确写法：user:{1001}:profile、order:{1001}:items、cart:{1001}:pending
• 错误写法：user:1001:profile（整个字符串参与哈希，和 order:1001:items 基本不会同 slot）
• 嵌套花括号只取最内层一对，user:{abc{def}:xyz 实际取 def 做哈希
• 如果 key 本身不含业务 ID（比如用 UUID），就得在写入前人工提取/约定一个稳定字段塞进 {}

EVALSHA 在集群里能用，但得先 SCRIPT LOAD

EVALSHA 不是万能的“绕过”方案——它只是用 sha1 替代脚本体发送，但校验逻辑完全一样：仍要求所有 KEYS 同 slot。不过它比 EVAL 少传脚本内容，网络开销小，适合高频调用。

关键点在于：SCRIPT LOAD 必须发给目标 slot 所在的节点（不能随便连一个集群节点），否则后续 EVALSHA 会报 NOSCRIPT No matching script。

• 实操建议：用 CLUSTER KEYSLOT key_name 查出某个 key 的 slot，再用 CLUSTER GETKEYSINSLOT slot count 或客户端路由能力定位对应节点
• 更稳妥做法：在应用启动时，对每个常用 key pattern（如 user:{*}:*）选一个代表 key，算出 slot，连接对应节点执行 SCRIPT LOAD
• 别把 SCRIPT LOAD 当成一次性的——集群扩缩容、节点故障后，脚本可能丢失，需重载

本地缓存 + 单 key Lua 是集群中最稳的组合

如果你的业务其实只需要原子地操作单个 key（比如限流、库存扣减、状态翻转），那直接用 EVAL + 单个 KEYS[1] 就行，完全不碰 CROSSSLOT 问题。

这时候真正的复杂点不在 Lua，而在怎么把原本要分散处理的逻辑，收敛到一个 key 上。比如“用户订单总数”不要存在 user:1001:order_count，而存在 stats:{1001}:orders；“购物车商品数”存在 cart:{1001}:size。

• 性能影响：单 key Lua 在集群中和单机 Redis 几乎无差别，延迟可控
• 兼容性：所有 Redis 4.0+ 集群都支持，不依赖客户端特殊能力
• 容易踩的坑：用 INCRBY 这类原生命令就能解决的，别硬套 Lua——增加不必要的 eval 开销和调试成本
• 真正难的是前期 key 命名设计，一旦上线，改 key 结构的成本远高于改 Lua 脚本

slot 对齐这件事，没法靠运行时补救，只能靠命名规范和建模阶段想清楚。