Redis集群环境如何存取数据：理解Slot槽位映射与Key分布原理
在Redis集群里存取数据，核心在于理解Key如何被分配到固定的16384个槽位中，以及客户端如何找到正确的节点。这个过程看似复杂，其实遵循着一套明确且固定的规则。掌握它，就能避免那些令人头疼的“MOVED”错误和跨槽操作问题。
CLUSTER KEYSLOT 命令查槽位最直接
想知道一个Key到底落在哪个槽？最直接的办法，就是连上集群任意节点，执行一条命令：CLUSTER KEYSLOT 。比如，输入CLUSTER KEYSLOT “user:1001”，返回12345，答案一目了然——这个Key属于12345号槽。
这里有几个关键细节需要注意：
- 该命令一次只接受一个Key，不支持批量查询或通配符。
- 如果Key包含了哈希标签（即
{}），比如{user:1001}:profile，命令会自动提取花括号内的内容（user:1001）来计算槽位。这正是确保像{user:1001}:profile和{user:1001}:settings这类关联Key能落到同一个节点的底层机制。
当然，也常有一些误解需要澄清：
- 它只返回槽号，不返回节点地址。 想知道12345号槽由哪个节点负责，得靠
CLUSTER SLOTS命令或者客户端自己维护的映射表。 - 它只在集群模式下有效。 在单机或非集群模式的Redis实例上执行，会直接报错：
(error) ERR This instance has cluster support disabled。
crc16(key) % 16384 是硬编码规则，不可自定义
Redis集群的槽位分配，可不是什么可配置的选项，而是一条“铁律”：对Key字符串进行CRC16校验和计算，然后对16384取模（为了性能，实际用位与操作crc16(key) & 16383实现）。所有官方客户端，无论是Python的redis-py还是Ja va的lettuce，都内置了这套完全相同的算法。
这意味着什么？
- 确定性。 同一个Key，在任何Redis集群、任何客户端里计算出的槽号永远一致。这为数据迁移提供了便利，无需重新哈希。
- 不可替代性。 如果你想自己实现槽位计算，必须使用标准的CRC16算法。换成MD5、SHA1，甚至Python内置的
hash()函数，结果都会错位，必然导致操作失败。 - 实现一致性。 不同编程语言的CRC16库可能存在细微差异（比如初始值或字节序）。务必确认你使用的库输出的是16位无符号整数，才能保证计算结果与Redis官方实现匹配。
MOVED 错误不是失败，而是路由重定向信号
当你直接连接到一个节点（例如127.0.0.1:7000）去操作一个不属于它的Key（比如GET user:1001）时，通常会收到这样的回复：MOVED 12345 127.0.0.1:7002。
千万别把这当成错误。这其实是集群在友好地提醒你：“这个Key在12345号槽，它归7002号节点管，请去那边操作。” 一个成熟的集群客户端应该做到：
- 解析这个响应，提取出槽号（12345）和目标节点地址（127.0.0.1:7002）。
- 立即更新本地缓存的“槽位-节点”映射表，避免下次请求同一个槽时再次走错路。
- 自动将原请求重新发送到正确的节点。
如果你使用的是最基础的TCP连接，或者像redis-cli没有以集群模式启动（记得加-c参数），就会卡在这里，反复看到MOVED错误。所以，确保你的客户端启用了集群支持，是顺畅操作的第一步。
哈希标签 {} 是唯一可控的“绑定”手段
我们无法指定一个Key必须存放在某个槽或节点，但Redis提供了一个巧妙的“后门”：哈希标签。只要多个Key拥有相同的{xxx}部分，它们就注定会被分配到同一个槽里。
来看一组典型的应用：
SET {order:123}:items “a,b,c”HSET {order:123}:status state “shipped”EXPIRE {order:123}:lock 60
这三个Key都只根据order:123来计算槽位，因此它们可以安全地在同一个Lua脚本中被原子化操作，完全不用担心触发CROSSSLOT错误。
使用哈希标签时，得清楚它的边界：
- 一对原则。 花括号
{}最多只能出现一对。像{{user:1}}:name这样的嵌套是无效的，系统会在遇到第一个}时就停止提取。 - 内外有别。 只有
{}内的内容参与计算，外部字符被忽略。所以，user:{123}:name和cache:{123}:meta会落到同一个槽，但user:123:name（没有花括号）则会用整个字符串来计算，结果很可能不同。 - 性能提示。 对于没有哈希标签的长Key，整个字符串都会参与CRC16计算，理论上会带来微小的性能开销。
最后，还有一个容易被忽略但至关重要的点：槽位分配表的更新并非实时同步。集群依赖Gossip协议在节点间异步传播元数据变更。这意味着，在完成数据迁移（resharding）后的短暂时间内，部分客户端可能还持有旧的槽位映射，从而遇到MOVED或ASK重定向。遇到这种情况，先别急着重启客户端，等待几秒让信息同步，或者主动执行一次CLUSTER NODES来刷新本地视图，往往是更稳妥的做法。
