Redis集群中MSET报CROSSSLOT错误，因key默认散列到不同槽；须用Hash Tag（如{1001}）强制多key同槽，且需验证槽位一致、tag低基数、分布均匀。

Redis集群中直接用MSET批量写多个key，大概率报CROSSSLOT Keys in request don't hash to the same slot错误——这不是命令写错了，是集群分片机制在拦你。

为什么MSET在Redis集群里默认不工作

Redis集群把16384个哈希槽分给不同节点，每个key按CRC16值对16384取模决定归属槽位。没加任何标记时，user:1001:name和user:1002:email算出来的槽位几乎必然不同，MSET一发过去就被拒绝。

• MSET本身不要求原子性跨节点，集群也不支持；它只允许所有key落在同一槽位上才执行
• 单机Redis下MSET是原子的，集群里“原子性”退化为“同槽位+单节点内执行”，不是全量成功或全量失败
• 哪怕两个key只是ID差1（比如user:999和user:1000），只要没共享hash tag，就可能跨槽

Hash Tag怎么让多个key强制落到同一槽位

Redis计算槽位时，会先扫描key字符串：如果遇到第一个{，就只取它和紧随其后的第一个}之间的内容做CRC16；其余部分全忽略。

Redis Skill - 高性能缓存管理

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

下载

• user:{1001}:name → 槽位由1001决定
• user:{1001}:email → 同样由1001决定 → 和上面同槽
• order:{1001}:status → 还是由1001决定 → 可一起MSET
• user:{1001}:{name} → 仍只认第一个{到第一个}，效果等同user:{1001}:name
• 没花括号？那就整个key参与计算，比如user:1001:name → 槽位由完整字符串决定

实际写MSET前必须验证的三件事

加了{}不等于万事大吉，用错反而埋坑。

• 业务上这些key真属于同一个聚合单元（比如一个用户的所有字段），且读写频率、过期策略、生命周期基本一致
• tag内容不能是高基数字段：避免用{1651324800}（时间戳）或{a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8}（UUID），否则tag散列太开，起不到聚合作用
• 检查tag分布是否均匀：比如全用{1}，所有数据砸进一个槽，那个节点立刻变瓶颈；可用user:{1001%16}:name这类逻辑，但得在客户端算好再拼key，Redis不解析表达式

用CLUSTER KEYSLOT快速验证key是否同槽

上线前别靠猜，用命令直查槽位分配是否符合预期。

• 连上任一集群节点，执行：CLUSTER KEYSLOT user:{1001}:name
• 再执行：CLUSTER KEYSLOT user:{1001}:email，两个返回值必须完全一样
• 如果不一样，说明{}位置写错、多写了空格、或者用了中文括号｛｝（Redis只认ASCII {和}）
• 顺手查下目标槽当前负载：CLUSTER COUNTKEYSINSLOT 1234（把1234换成实际槽号），数值过大就得重新评估tag设计

真正容易被忽略的是：Hash Tag解决的是“能不能批量”，不是“要不要批量”。即使key都在同一槽，MSET在集群里仍是单节点内原子，但整个操作不提供事务回滚能力；如果业务强依赖多key全成功/全失败，得切到Lua脚本里用redis.call()包裹，且同样要确保所有KEYS带相同tag。