Redis 集群批量操作多 key 报错 CROSSSLOT 的根本原因是 key 分散在不同哈希槽，优化核心是使用 Hash Tag 强制相关 key 落入同一槽位。此方案适用于 MSET、MGET、DEL 等多 key 命令，但需注意避免数据倾斜风险。

命令速用版

直接通过 redis-cli 验证 key 槽位并执行修正后的批量命令，确保所有 key 哈希值一致。

CLUSTER KEYSLOT user:{1001}:name
CLUSTER KEYSLOT user:{1001}:email
MSET user:{1001}:name "Alice" user:{1001}:email "alice@example.com"

为什么会这样

Redis 集群将数据分为 16384 个槽位，多 key 命令若跨槽位执行会破坏原子性一致性。

集群模式下，每个 key 通过 CRC16(key) % 16384 计算所属槽位。默认情况下，user:1001 和 user:1002 的哈希值不同，导致槽位不同。Redis 集群设计不允许跨节点保证多 key 操作的原子性，因此当命令涉及多个不同槽位的 key 时，服务端直接拒绝执行并返回 CROSSSLOT 错误。

分步处理

按步骤改造 key 结构并验证槽位分配，确保业务逻辑兼容同槽限制。

1. 识别报错命令：检查代码中涉及多 key 的命令，如 MSET、MGET、DEL、SUNION 等。

2. 设计 Hash Tag：提取业务上属于同一聚合单元的标识符，用花括号包裹。例如将 user:1001:name 改为 user:{1001}:name。

3. 验证槽位一致性：在 redis-cli 中执行 CLUSTER KEYSLOT 命令，确认所有相关 key 返回的槽位编号完全相同。

4. 评估数据倾斜：检查 Tag 内容是否为高基数字段，避免所有数据落入同一槽位导致单节点热点。

怎么验证是否生效

通过对比修改前后 key 的槽位编号及命令执行结果，确认 CROSSSLOT 错误消失。

执行 CLUSTER KEYSLOT user:{1001}:name 和 CLUSTER KEYSLOT user:{1001}:email，若返回值一致且原报错命令执行成功，则优化生效。同时观察集群节点负载，确认未出现单槽位数据量过大的情况。

常见坑

Hash Tag 使用不当可能导致数据倾斜或命令依然报错，需避开无效写法。

1. 花括号未闭合或为空：如 user:{1001 或 user:{}，会导致 Redis 退化为全 key 哈希，失去强制同槽效果。

2. 单 key 命令误用：INCR、LPOP 等单 key 命令本身不支持多 key 操作，加 Hash Tag 无法解决跨 key 需求。

3. 高基数 Tag 导致倾斜：若 Tag 内容为 UUID 或时间戳，可能导致数据无法均匀分布，形成热点节点。

常见问题

Lua 脚本在集群中报 CROSSSLOT 怎么办

Lua 脚本涉及的所有 key 也必须通过 Hash Tag 落在同一槽位，且 KEYS 参数需显式传入带相同 Tag 的 key。

MGET 命令是否支持跨槽位获取

不支持，MGET 在集群模式下要求所有 key 必须在同一槽位，否则需拆分为多次单 key 请求。

Hash Tag 会影响数据分布均匀性吗

会，若 Tag 内容基数过小（如全用{1}），会导致数据集中在一个槽位，需确保 Tag 内容有一定离散度。