标准答案
- 每个 Key 会按哈希映射到一个槽位，再由某个主节点负责；扩容或缩容时迁移的是槽位及其 Key，不是任意按业务表拆分。
- 跨槽位的多 Key 命令、事务和 Lua 脚本通常受限。确实需要同槽原子操作的 Key 可使用相同 hash tag，例如 order:{123}:status 与 order:{123}:items。
- hash tag 应只放真正需要绑定的业务维度；把所有 Key 固定到同一个 tag 会让分片失效，形成热点节点。
- 客户端必须使用支持 Cluster 重定向、拓扑刷新和故障切换的驱动，并对迁槽、短暂重试和连接池行为做压测。
题目解析
分片约束会反推数据模型。若一个操作需要频繁跨用户、跨订单做事务式集合运算，Redis Cluster 不是让它自动保持原子性的理由，可能需要调整边界或回到数据库事务。
Key 设计还应兼顾租户与热点。按单租户 hash tag 可能便利了原子操作，却会让大租户独占一个分片，需要根据实际分布做二级分散。
代码示例
同一对花括号中的内容参与 hash tag，以下两个 Key 可以落到同一槽位。
Text
cart:{user-1001}:items
cart:{user-1001}:version
cart:{user-1002}:items常见误区
- 把所有业务 Key 都放进同一个 hash tag，导致 Cluster 退化成单分片。
- 在跨槽位场景直接依赖多 Key 原子命令，却没有验证客户端和命令限制。