Redis集群通过CRC16算法对key（或其Hash Tag）哈希后对16384取模确定Slot编号（0–16383）；仅依赖key字符串本身，支持{}提取Hash Tag，且必须使用ITU-T X.25标准CRC16实现。
Redis集群怎么确定一个Key落在哪个Slot上
Redis集群用CRC16算法对
做哈希，再对16384取模，结果就是它所属的Slot编号（0–16383）。这个过程不看value、不看命令类型、也不受客户端驱动影响——只取决于
字符串本身。
注意：如果
含大括号（如
），Redis会提取最内层
之间的内容作为哈希输入，也就是只对
算CRC16。这是为支持Hash Tag，让相关key落到同一节点。
没大括号 → 对整个
字符串计算
有大括号 → 只取第一个
内的子串，如
多个
或嵌套？只认第一个合法闭合对，其余忽略
CRC16实现不一致会导致Slot错位吗
会，而且很隐蔽。Redis服务端用的是ITU-T X.25标准的CRC16（初始值0xFFFF，多项式0x1021，低位先入），不是常见的Modbus或ZIP变种。如果你在客户端自己实现哈希逻辑，或者用第三方库硬编码了别的CRC16，算出来的Slot就和Redis实际分配的对不上。
典型现象：客户端认为
该发往Node A，但Redis集群返回
重定向到Node B；或者使用
时报告slot分布不一致。
别手写CRC16——优先调用Redis客户端内置的
方法（如Jedis的
、node-redis的
）
Python用
时，
已封装正确逻辑
若必须手动算，确认CRC16函数参数：poly=0x1021, init=0xFFFF, xorout=0x0000, refin=True, refout=True
为什么是16384而不是65536或其它数
16384（即2¹⁴）是权衡结果：足够分散负载，又控制心跳包开销。每个节点需在Gossip消息中广播自己负责的slots位图，16384 bit ≈ 2KB，而65536 bit就要8KB——集群规模大时，这直接影响通信效率和收敛速度。
另外，Redis官方明确不支持运行时调整slot总数，16384是硬编码在源码里的常量（
），改它等于fork一个私有版本。
不能通过配置增大或减小slot数量
扩容/缩容靠迁移slot，不是新增slot空间
单个slot只能由一个主节点负责，但可有多个从节点
遇到MOVED/ASK重定向说明什么
表示请求的
当前归属另一个节点，且该映射关系已稳定（比如完成了一次slot迁移）；
则表示slot正在迁移中，本次请求临时去目标节点查，但后续仍应发给源节点——直到收到下一次
。
这两类响应不是错误，而是集群正常协作机制。客户端必须解析响应内容里的
并跳转，否则会持续失败。
→ 更新本地slot 1234的路由缓存，下次直连
→ 本次请求加
指令后重发，不更新缓存
某些老客户端（如早期Lettuce）未正确处理
，导致迁移期间读写失败
真正容易被忽略的是：哈希结果依赖
字面量，而非序列化后的二进制。比如用JSON序列化对象当
，字段顺序、空格、换行稍有不同，CRC16就完全不同——这种差异在线上环境极难排查。
keykeykey"user:{1001}:profile"{}"1001"keyCRC16("mykey") % 16384{}CRC16("1001") % 16384{}"order:123"MOVEDredis-cli --cluster checkkeySlot()ClusterCommand.getSlot(key)Cluster.getSlot(key)redis-pyRedisCluster.keyslot("mykey")REDIS_CLUSTER_SLOTSMOVEDkeyASKMOVEDip:portMOVED 1234 10.0.1.5:6379ASK 1234 10.0.1.5:6379ASKINGASKkeykey