Redis集群中MSET或PIPELINE报CROSSSLOT错误，因跨槽key被拒绝；Hash Tag（如user:{1001}:name）通过{}内内容决定槽位，使同tag的key路由至同一节点，从而支持批量操作。
为什么直接用 MSET 或 PIPELINE 在 Redis 集群里会报错
Redis 集群要求同一个命令涉及的所有 key 必须落在同一个哈希槽（slot）上，否则会返回 CROSSSLOT Keys in request don't hash to the same slot。像 MSET user:1001:name "Alice" user:1002:name "Bob" 这种跨槽批量写入，在集群模式下默认被拒绝——因为 user:1001:name 和 user:1002:name 的 CRC16 值不同，大概率分属不同节点。
Hash Tag 是什么，以及它怎么强制 key 落在同一槽位
Redis 对 key 计算槽位时，不是对整个 key 字符串做 CRC16，而是先检查 key 中是否包含一对花括号 {}；如果存在，只取第一个 { 和紧随其后的第一个 } 之间的内容作为哈希依据。其余部分被忽略。
-
user:{1001}:name→ 槽位由1001决定 -
user:{1001}:email→ 同样由1001决定 → 和上面同槽 -
order:{1001}:status→ 也由1001决定 → 可与前两者一起MSET -
user:{1002}:name→ 由1002决定 → 和1001不同槽
注意：只认第一个 {...}，user:{1001}:{name} 和 user:{1001}:name 效果完全一样；嵌套或多个 {} 不会叠加解析。
批量操作前必须确认的三件事
Hash Tag 不是万能胶水，用错反而引发数据倾斜或逻辑混乱：
- 业务上这些 key 确实属于同一聚合单元（比如一个用户的所有字段），且生命周期、访问模式高度一致
- Tag 内容不能是高基数字段（如时间戳、UUID），否则导致槽位分散失效；推荐用业务主键（如
user_id、order_id） - 避免过度集中：所有
user:{1}:*全打到一个槽，可能压垮单个分片；需评估 tag 分布是否均匀（例如用user:{1001%16}:name做二次散列要谨慎，Redis 不支持表达式，只能客户端算好）
实际写法示例：用 Hash Tag + PIPELINE 安全批量写入
假设你要存一个用户的 name、email、age，且保证原子性读写，正确做法是：
MSET user:{1001}:name "Alice" user:{1001}:email "alice@example.com" user:{1001}:age "30"
在客户端代码中（以 Python redis-py 为例）：
pipe = r.pipeline()
pipe.mset({
"user:{1001}:name": "Alice",
"user:{1001}:email": "alice@example.com",
"user:{1001}:age": "30"
})
pipe.execute()
错误示范（看似简洁但失败）：
# ❌ 报 CROSSSLOT 错误
pipe.mset({"user:1001:name": "...", "user:1001:email": "..."})
# ❌ tag 不匹配，还是跨槽
pipe.mset({"user:{1001}:name": "...", "user:{1002}:email": "..."})
Hash Tag 的生效依赖 key 字符串字面量 —— 客户端拼接时别漏掉花括号，也别加空格（user:{ 1001 }:name 中的空格会被计入，导致哈希结果变化）。
真正难的不是语法，是判断哪些业务维度天然适合聚合成一个 tag；一旦选错，后续扩缩容、数据迁移、故障恢复都会更棘手。
