CROSSSLOT错误本质是Redis Cluster强制拒绝跨槽多key操作，因ZUNIONSTORE等命令需单节点原子执行，跨槽即报错；唯一合规解法是用{}哈希标签使所有key同槽，或客户端聚合。
CROSSSLOT 错误本质是跨槽操作被拒绝
在 Redis Cluster 模式下，SUNION、ZUNIONSTORE 这类多 key 命令要求所有 key 必须落在同一个哈希槽（slot）里。如果两个 ZSet 的 key 经过 CRC16 哈希后映射到不同 slot（比如 rank:2026 → slot 1234，backup:rank → slot 5678），Redis 就会直接返回 CROSSSLOT Keys in request don't hash to the same slot 错误。这不是客户端 bug，是集群协议强制限制——因为并集逻辑必须由单个节点原子执行，跨节点协调成本太高，干脆禁止。
ZUNIONSTORE 在集群中根本不可用
和单机 Redis 不同，Redis Cluster 的设计原则是「命令要么完全支持，要么明确不支持」。ZUNIONSTORE 属于后者。即使你用 redis-cli -c 连接集群，执行 ZUNIONSTORE dest 2 zset1 zset2 依然会报 CROSSSLOT。官方文档明确列出该命令在集群模式下不可用，不是兼容性问题，是架构取舍。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
替代方案只有客户端聚合或重定向 key
真正能落地的解法就两条路：
- 用
ZRANGE zset1 0 -1 WITHSCORES和ZRANGE zset2 0 -1 WITHSCORES分别拉取全部成员+分数，在客户端做合并（去重、按 score 排序、处理相同 score 的字典序），再用ZADD dest批量写入新 ZSet —— 适合数据量可控（比如万级以内）、允许短暂延迟的场景 - 强制让多个 ZSet key 落在同一个 slot：给 key 加上相同哈希标签，例如都写成
{user}:rank:2026和{user}:backup:rank（花括号内内容决定 slot），这样它们必然路由到同一节点，ZUNIONSTORE就能用了 —— 但代价是丧失分片均衡性，所有带{user}标签的 key 都挤在一个节点上
别信“自动重试”或“客户端智能路由”
某些旧版客户端（如早期 Jedis）遇到 MOVED 或 ASK 会自动重定向，但 CROSSSLOT 是硬性拒绝，不会触发重定向逻辑。Redisson 的 RedisTemplate 如果底层用的是 Redisson 自己的连接池，还可能因未实现 ZUNIONSTORE 导致 StackOverflowError（它把调用循环转发给自己）。最稳妥的方式，永远是先确认你的客户端实际走的是哪个连接工厂、是否真正发到了目标节点。
